Так что нужно выбрать? И какие критерии вкладывать в слова «гибко» и «быстро».
Есть много подходов к реализации и управлению проектами.
Вот одни из них:
- PMBoK (Project Management Body Of Knowledge) - классический подход в котором участвуют все процессы проектирование, рисков, управления ресурсами и т.д.
- Waterfall - из названия можно понять, что это водопадная модель, при которой вы идёте от шага к шагу. Закончили одно, приступаете к следующей итерации. Вроде четкий и понятный roadmap (дорожная карта)
- Agile - у всех на слуху, но как ей пользоваться знают единицы. В принципе как и о первой методологии :)
Итак, я приверженец последней методики, но расскажу про каждую.
- PMBoK - Классная штука, если хочется досконально всё узнать, и бороться со скукой, или не бороться если вам нравится бумажная волокита. Никак не принижаю такой подход, сам сдавал на него экзамены еще на 5-ю версию в PMI и даже когда-то был в ТОП-500 участников Российского общества PMI, сидел с дядьками слушал разные истории про проекты. С помощью PMBoK можно и мобильные приложения написать и космические корабли строить. Но выбор не наш, пока всё спланируешь, бизнесу это уже не нужно «поезд ушел» :) Но всем рекомендую хотя бы поверхностно прикоснуться к этой методологии, и пожалуйста без фанатизма.
- Самая распространенная модель! Даже многие кто говорит, что управляет по Agile, на самом деле работает именно по этой модели. Эту вещь любят все руководители. Четко, понятно, есть roadmap, можно привязать KPI, контролировать и наказывать нерадивых разработчиков :)
- Agile - кажется, что это придумали разработчики, чтобы меньше работать и больше пить кофе в старбакс. Но это не так :) Придумали её дядьки из первой модели. Неожиданно да?! :) В 6-й версии PMBoK, если мне не изменяет память, ввели как раз такое понятие как Agile, и даже выпустили отдельную книгу и курс. Гибкая методология в основном используется для разработки продуктов в сфере ИТ, где можно безболезненно отказаться от уже готового функционала и переписать его в сторону актуальности для бизнеса. (Кто сомневается, что эта методология в основном для ИТ, попробуйте в процессе строительства многоэтажного дома, изменить фундамент под подземную парковку)
Это самые распространенные методологии, не будем окунаться в дебри и бить себе в грудь, что я не упомянул о "самой крутой методологии".
По-моему выбор очевиден нам нужен Agile подход. Именно он позволяет быстро проверять гипотезы, готовить пилоты, переводить их в MVP и в промышленную эксплуатацию.
Разбиваете большую задачу на подзадачи, их еще мельче и так до адекватного минимума (как правило не более 8 часов на задачу) Далее задачки приоритезируются, и начинаем делать. В процессе может оказаться, что «мы идем не тем путём», всё или часть обнуляется и начинаем переделывать :)
И так, обычно, каждые 2 недели, на каждом этапе заказчик получает какой-то конечный продукт, и пробует его в бизнесе. Вообще, мне кажется выражение «тяп, лап в продакшн!» пошло именно из этой методологии :)
Из больших минусов такой методологии, это то, что команду очень трудно заменить, разработчики должны быть очень вовлечены в бизнес-процессы, и уход даже одного разработчика резко притормаживает процесс.
На своей практике, Agile не раз меня выручал, можно спрогнозировать много работ, и даже согласовать с заказчиком, но на практике выдавая ему порции готового функционала, часто, уже на середине проекта, он говорит - «всё ребят, мне достаточно, я свою задачу выполнил» или «ребята, пришла новая распоряга, надо кое что переделать, в компании поменялась концепция», и даже так - «это больше не актуально, мы проверили гипотезу, это не «выстрелит» всё в «топку».
Последний вариант конечно обидный для разработчиков, люди они как правило творческие, и для них это как сжечь черновик мертвых душ 2-й версии :)
Как этого не делать постараюсь рассказать дальше. Т.к. когда мы писали свою платформу таких желаний было полно, но мы из этих минусов сделали только плюсы (хотя в топку отправлялось не мало :)