Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий
Шрифт:
Можно повторно замерить настроение команды, убедиться, что ребята считают, что меры помогут.
Можно спросить обратную связь на ретроспективу.
Если все недовольны решениями, ретроспективой – вы в беде. Очень жаль. Надо чинить ретроспективу.
3.8.2. Форматы фиксации
Мы используем три формата ретроспектив.
1) Неформальные. Короткая встреча на 15–30 минут, где по очереди даем высказаться всей команде. Плюсы, минусы, идеи, предложения. Конкретные решения фиксируем, если все с ними согласны – забираем в план работ. Подходит, если на проекте все хорошо. Просто градусник. Артефактов не остается.
2) Формат
Самое муторное потом – перенабрать писанину со стикеров и завести реальные задачи в тикет-системе. Но вы взросленькие, как-нибудь справитесь.
3) Электронные шаблоны.
Грамотный шаблон фиксации доступен в Confluence. Мы используем чуть попроще. Главное – вывести его на большой экран, чтобы все видели, как идет фиксация, и что ничего не забыто и не переврано.
< image l:href="#"/>3.9. Канбан. Когда лучше, чем scrum
Канбан – легковесный и прозрачный процесс. Задачи по мере поступления вывешиваются на доску, с которой разработчик может их забирать и программировать.
Канбан-доска технической поддержки. Фрагмент.
В отличие от Scrum-а, тут нет спринтов. Канбан больше подходит для контроля текущей техподдержки, маркетинга или обработки лидов. В разработке новых функций и версий лучше работает Scrum.
3.10. Куда дели менеджера
В теории нет разницы между теорией и практикой. А на практике есть.
Допустим, мы создаем продукт in-house. Собрали разработчиков в одной комнате, сказали работать по Скраму. Самоорганизуйтесь там как-нибудь. Получится? Маловероятно. На хакатон дня в три, может, и хватит, а на полноценный продукт уже нет. И канонический скрам-мастер тут вряд ли поможет.
Самоорганизующейся команде нужен самоорганизатор.
Другой пример. Вот идет разработка. Ни шатко ни валко, по ТЗ. Скорость медленная, баги, Product Owner ругается, команда грустит. Решают попробовать Scrum, а вдруг поможет. Опять нужен кто-то, кто сможет все самоорганизовать, сшить старые процессы с новыми, перевести работу на новые рельсы. Это искусство, тут много дел.
Или, допустим, заказная разработка. Product Owner на стороне клиента есть. Как-то на одной из встреч представитель клиента сказал на полном серьезе: «Да, у нас есть Product Owner, их целых 5» (ой!).
Что ожидается со стороны подрядчика? Что будет кто-то ответственный за проект, с кем можно вопросы порешать. А то и вовсе Proxy-Product-Owner нужен, который за заказчика все порешает, всю обратную связь со всех этих пяти Product Owner (корректнее называть их стейкхолдерами) соберет, решит противоречия и в случае чего – по башке получит. П – перспективы…
Менеджер делает все то, что нужно делать, но что не делает никто другой.
Или, как минимум, организует и делегирует, чтобы делалось все то, что почему-то никто не делает.
Но вот команда взрослеет, Scrum уже отлажен, все привыкли друг к другу и процессу, есть внутрикомандный scrum-мастер. В этом случае роль менеджера действительно уменьшается. И во что он трансформируется – вопрос на вырост. Может, в скрам-мастера. А может, в продуктового
менеджера, или аналитика, или помощника Product Owner.Кажется, редкие-редкие команды достигают такого дзена, где менеджер не нужен. Да и не в нашей ментальности работать без начальства. Короче, менеджер необходим и востребован, аллилуйя.
Можно ли совмещать в себе несколько ролей сразу? Быть и скрам-мастером и Product Owner? Технически – да, я такое видел в молодых командах. Но это антагонистические роли. В них специально зашит конфликт. Product Owner хочет больше и быстрее от команды, и менять все в любой момент. Scrum Master хочет, чтобы команда спокойно работала, и процесс не ломался. Сможете вы такое в своей голове удержать (быть и добрым, и злым), или начнет шизофрения развиваться? Хорошего-то мало. Я бы начал выращивать scrum-мастера внутри команды. Благо – это несложно, дня за три можно справиться.
3.11. Аналитика, дизайн, разработка – параллельно
Обычно нужно несколько спринтов, чтобы получился MVP (minimum viable product) – минимальный жизнеспособный продукт. MVP должен быть клевенький.
Цепкий, энергичный менеджер может организовать параллельную работу над аналитикой, дизайном и кодом. В Scrum-е спринт по аналитике запускаем чуть заранее. За ним – дизайн. И далее уже код. Примерно по такой схеме (правда не факт, что у вас будет так много дизайна и аналитики, но вдруг?).
При параллельной разработке нагрузка на менеджмент и коммуникации растет чуть ли не экспоненциально. Поэтому подход не для новичков, а для матерых организаторов.
3.12. Документация
Agile-манифест (которому сто лет в обед) – набор правильных лозунгов, которые как-то надо адаптировать к практике:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.
Agile-манифест разработки программного обеспечения. 2001 год.
В зрелом продукте документация нужна, Agile это не отрицает. В небольших web-проектах и приложениях – можно и без нее. Степень замороченности прямо пропорциональна объему проекта, педантизму заказчика и ресурсам. Правда, документация всегда немного отстает от реальности, и это окей.
Работая над SingularityApp, например, я беру какую-то крупную хотелку из бэклога и расписываю, как бы я хотел, чтобы она работала с точки зрения пользователя. Это просто схемки интерфейсов на iPad, скриншоты похожих реализаций и немного текста. Если нужно докрутить формальности – отдаю аналитикам (с проверкой, чтобы не исказили идею). Там уже могут появляться прототипы, описание граничных случаев, интеграционные протоколы и так далее, если мне нужна такая степень проработки и формализма. Такие штуки удобно хранить в Confluence или википедии проекта. Подойдет и Google Docs.