Привет, дорогой читатель!

В предыдущей статье я рассказал, как в 2017 году попытался внедрить гибкий подход к разработке ПО и созданию сайтов на основе Scrum.

Перед прочтением данной статьи, прочитайте предыдущую для большего понимания, что тут вообще происходит.

Модные слова и словосочетания

Скорей всего Вы тоже слышали и не раз различные модные слова такие как: голубой океан, гибкие подходы к разработке, канбан, agile, скрам, покер планирование и другие различные словосочетания, которые часто используются в IT сфере.

По моим наблюдениям и общению с другими разработчиками, я сделал небольшой вывод: по сути в большинстве компаний все что используется от скрама — это обычная доска и спринты. Да и то, доска это просто список задач, который из себя доску то не представляет, а обычный список отсортированный по дате.

Но даже к примеру спустя эти 3 года, до сих пор встречаюся компании в которых использование Agile, Scrum или Kanban выдается за конкурентное преимущество перед другими IT компаниями, которые используют тоже самое.

Хотя на собственной практике и опыте я понял, что собственника бизнеса волнуют совсем другие показатели, а технического специалиста — другие. И по большому счету им все равно какие вы используете методологии. У них свои заботы и вряд ли они будут влезать в ваш рабочий процесс.

Спустя 3 года работы над проектами

С того момента, как я попытался внедрить Scrum прошло уже 3 года и поработав в компании, над собственными проектами и разрабатывая проекты на заказ, стало приходить понимание в какую сторону необходимо двигаться и развиваться.

Что необходимо действительно учесть в работе, как перестроить процессы разработки, как лучше взаимодействовать с собственной командой, улучшение методов взаимодействия с другими командами, которые принимают участие в проекте.

Выводы которые сделал лично для себя

  1. Не стоит внедрять различные инструменты только потому что они есть почти у всех. Или просто звучит круто и модно. Это ни к чему хорошему не приведет.
  2. Не нужно внедрять все в чистом виде. Это бесполезно. Необходимо подстраивать под себя и процессы компании.
  3. Понимать на что способен каждый участник в команде. Это позволяет в определенных случаях получить максимум результата по какой-нибудь задаче, чем от другой участника . Когда ты знаешь что они умеют делать, то и задачи могут быстрее решать и работа будет сделана более качественно.
  4. Клиенту по большому счету все равно какие вы там используете методологии. Гибкие, твердые, сырые, солнечные, волнистые, зигзаговые и т.д. Он заплатил деньги и хочет получить либо еще больше денег, либо сократить будущие издержки за счет получения Вашей услуги.
  5. Необходимо уметь управлять выгодами, которые необходимо достичь при помощи проекта. Так как от этого зависят шаги реализации и процесс работы над проектом.
  6. Как более правильно выстроить presale заказчику по разработке проекта ПО на заказ или более сложного сайта.
  7. Оттачивайте навыки переговоров для работы как с клиентами, так и со сторонними командами. Они особенно понадобятся вам при работе над проектом.
  8. Изучайте и накапливайте базу рисков проекта, методов минимизации и реагирования на них.
  9. Обозначить свои конкурентные преимущества перед другими, а не только за счет использования Agile

И самое главное на мой взгляд:

То что описано в Scrum, ведь мы это делали и до этого. Общались с клиентом, определяли важные задачи, показывали промежуточный результат, ставили дедлайн и действительно выполняли в срок. А если были трудности, то подключались другие люди, у которых больше компетенций и знаний в определенной области.

Просто мы не называли это Agile, Scrum, Kanban или как-то по другому. Работали над проектом и все остальное происходило как бы само собой.

Поэтому лично я считаю, что не нужно бежать и внедрять какой-либо инструмент, только потому что он новый, модный, о нем говорят везде или используется почти у всех.

Необходимо рационально подходить к выбору и внедрению того, что действительно будет работать в вашей компании, команде и будет помогать добиваться нужных результатов.

Вне зависимости от того, как это называется.

Если это работает, приносит измеримый и полезный результат, значит нужно использовать.

Данные статьи подойдут в большей степени для начинающих разработчиков, либо тех кто делает первые шаги в управлении проектов.


Антон Чураков
Автор публикации
Антон Чураков
Руководитель IT-компании "Цифровой Волк"

Присоединяйтесь ко мне в социальных сетях, чтобы быть в курсе последних новостей и полезных материалов для вас и вашего бизнеса

Еще материалы из данной категории

Стоит ли внедрять и использовать KPI компаниям в 2021 году
Система KPI известна в любой компании, которая думает о своем будущем. И в любой компании, где она внедрена и применяется, найдутся скептики, сомневающиеся в ее эффективности. Особенно сегодня, когда COVID 19 негативно повлиял на все стороны нашей...
Участие в бизнес-премии Magic People IT-Channel Awards 2020
В начале года, мы вместе с командой впервые принимали участие в бизнес-премии Magic People 2020 проводимой компаний Axoft. Презентовали проект для регионального заказчика — сети АЗС. С новой онлайн системой по работе с топливными картами, в номинации...
В чем заключается сила и слабость свободного программного обеспечения
30 лет назад студент Хельсинкского университета Линус Торвальдс выпустил ядро Linux с открытым кодом и привлек помощников для разработки своей операционной системы. С годами свободное и открытое ПО уверенно завоевало место под солнцем...
Станут ли CIO влиятельней CFO, COO, CMO или нет
Как наша жизнь заметно изменилась во время распространения COVID-19, так и приоритеты в бизнесе не остались прежними. Среди тех, чей профессионализм помог компаниям удержаться на плаву, оказались ИТ-директора (CIO) – технологические лидеры. Будет ли...