Мир перевернулся, когда, после крупных матричных монстров, я пришла руководить в стартап. Пространство неопределенности в технологических проектах ( в моем случае - разработка ПО) так велико, что привычный Гант и жесткое планирование только тратят время и нервы.
И началось - книги, книги, книги. В современных бизнес- пособиях, написанных успешными предпринимателями, нашлась уйма советов мелкой россыпью, которые, вероятно, хорошо работают у них, и никак не ложатся в мою конкретную ситуацию. Потребовался универсальный инструмент, на основе которого можно строить свои собственные способы управления. Такой базой стал курс лекций Г.П. Щедровицкого “Оргуправленческое мышление” - все о системном анализе и его применении на практике.
В результате, не читая других методик управления, мы постепенно пришли к тому, что в англоязычной литературе называется Agile.
О терминологии, отличиях от устаревшей “каскадной” разработки и т.д. можно прочитать тут
https://cyberleninka.ru/article/v/optimizatsiya-uprav..
Ниже будет исключительно по-русски о нашем опыте работы в философии Agile.
1. Нет глубокого планирования - есть постоянная готовность к изменениям.
2. Нет жестких иерархических структур - есть небольшие мобильные группы, которые формируются по мере необходимости. Прямых начальников у них нет - это, кажется, самое необычное для нашего менталитета. Но, у нас трудностей не возникло - команда не так велика, чтобы тратить ее ресурс на сложную иерархию.
3. Группы несут взаимную социальную ответственность. Тут вспоминается Д. Ариэли, доказавший, что денежная мотивация работает в краткосрочной перспективе, тогда как социальные обязательства довольно долговечны.
4. Зато есть директор проекта (в классическом Agile - это Product Owner) Его задача - донести разработчикам потребности бизнеса. Как их реализовать, участники проекта решают сами.
5. Нет больших этапов работы - есть маленькие шаги в 1-2 недели (sprint)
Каждый спринт тут же выносится на продакшн - и мы не рискуем долго реализовывать что-то, что не будет востребовано в конечном итоге. Каждый спринт (независимо, front-end это или back-end) должен отвечать на вопросы “Что?”, “Как?”, “Зачем?”. А команда должна знать его ценность для проекта.
6. Необходимы открытые обсуждения работы и практических результатов (retro)
Тут важно помнить, что при достаточном количестве совещаний даже самую простую задачу можно сделать невыполнимой - все хорошо в меру.
7. В проекте не должно быть большого разнообразия технологий - можно запутаться, потерять время и новичков, если такие пришли в проект.
8. Любая доработка продукта/сервиса (fiche) должна предварительно оцениваться по прибыли, которую она принесет бизнесу.
9. Кросс-дисциплина. Говоря коротко: каждый участник проекта должен быть крут в своем деле и крайне заинтересован в остальных отраслях. Т.е. готов быстро обучиться и закрыть недостающий команде объем знаний.
По скольку у нас запустился еще один стартап, за последние полгода я срочно научилась писать контент, строить речевики для отдела продаж, прорабатывать пользовательские сценарии и интерфейсы - здорово, когда кросс-дисциплина не дает мозгу застаиваться.
10. Нельзя хранить информацию по проекту в голове - нужно документировать и держать в более-менее актуальном состоянии, чтобы:
- легко сменить команду при необходимости
- легко сменить технологии.
По этой же причине, разработку ПО ведут небольшими частями - контейнерами. Такие мозаичные системы хороши своей гибкостью - легко переписать/убрать один пазл, не нарушая работу всей системы.
11. Директор проекта, он же product owner, - не путаем с менеджером продукта. У первого охват гораздо шире - он взаимодействует и с бизнесом, и с потребителем и с самим менеджером продукта. И на основе их информации ставит задачи всей команде.
Надобно отметить, что вся эта гибкая, подвижная и довольно демократичная система подходит только для хорошо мотивированных людей. Поэтому, на собеседовании первым делом я выясняю мотивацию человека, вторым - достаточность знаний и навыков для работы, и наконец, впишется ли он в культуру компании.
Кстати говоря, знаменитая система Страж, которой пользуется ФРС, после нескольких неудачных попыток, создана с помощью методов Agile.
“Велосипеды не нужно изобретать. Велосипеды дешевле воровать.” (с)
Еще о базовых методах Agile - https://cyberleninka.ru/article/n/gibkaya-metodologiy..
https://i.arts.in.ua/i/7854/f_dirijer_kutukova_viktor..
