KISS для менеджеров на старте проекта

Денис Петров
Руководитель программы, MERA
SECR 2019

Способность выполнять небольшие и по размерам и по бюджету, но при этом насыщенные по функционалу проекты, является крайне полезной способностью организации. В моем докладе описываются ключевые практики командообразования, организации процесса разработки и взаимодействия с заказчиками, которые мы использовали при старте новых проектов последние 4 года в более чем 40 успешных (и не очень) небольших проектах. Все они из разряда KISS (Keep It Simple & Straightforward) и, несмотря на свою простоту, думаю, что наши выводы будут интересны как опытным менеджерам, так и тим лидерам, которых привлекает динамичная и гибкая организация работы.

Transcript

1. for PMs at project startup Denis Petrov MERA Software Engineering Conference Russia November 14-15, 2019. Saint-Petersburg
2. 2 Denis Petrov Program Manager MERA https://www.mera.com Linkedin https://www.linkedin.com/in/denis-petrov- 958a664 Contact
3. 3 • небольшая команда • небольшой бюджет • короткие сроки Введение: что такое небольшой проект
4. 4 Введение: почему важно уметь выполнять небольшие проекты
5. 5 • Традиционный подход слабо применим • Быстрота старта имеет существенное значение для успеха проекта • Полностью соответствующие потребностям проекта сотрудники – редкость, а стартовать надо сейчас • Взаимодействие с заказчиком важно, однако кто он – мы еще не знаем (это предстоит выяснять по ходу дела) Введение: почему KISS на старте проекта
6. 6 Собираем команду, нацеленную на: - оперативное взаимодействие с заказчиком - быстрое начало и выполнение работ Практики KISS при формировании команды
7. 7 Ядро всему голова («ядро» команды должно быть сформировано) История когда подписали контракт без команды
8. 8 Выбираем «спринтеров» История когда команда долго делала проект с фиксированной стоимостью
9. 9 «Кузнец нам не нужен» (необходимые в проекте роли может выполнять команда) История когда заказчик хотел архитектора с практическим опытом использования Thread
10. 10 С кем лучше идти в разведку (предыдущий опыт совместной работы обеспечит более эффективное выполнение задач) История когда 2 части команды начали ругаться друг с другом
11. 11 Кони должны быть свежие  История когда вторую версию доделывали на «последнем издыхании»
12. 12 • На начало проекта «ядро» команды должно быть сформировано и включать как ключевых инженеров, так и менеджера проекта. Если это не сделано, то проект лучше не стартовать, т.к. его фактическое начало будет отложено. • Важно включать людей с повышенной скоростью обработки информации. Например, это те, кому на чтение спецификации нужно 1-2 часа в сравнении со стайерами, которым может потребоваться 1 день. Практики KISS при формировании команды: итоги (часть 1)
13. 13 • Недооценивается фактор слаженности и комплиментарности команды. Это касается как стейкхолдеров внутри организации, так и заказчиков. Многие из них ожидают наличие обязательного опыта для выполнения определенных ролей в проекте. На практике необходимо, чтобы команда могла выполнять функции нужных ролей коллективно, либо кто-то в команде был способен в короткие сроки научиться делать задачи, связанные с какой-то ролью. • Желательно, чтобы ядро команды уже имело опыт совместной работы. Это позволит не тратить время «на притирку». • Стоит оценить степень «усталости» потенциальных членов будущей команды. Не стоит подключать людей с «выгоранием», «кони для погони должны быть свежие». Практики KISS при формировании команды: итоги (часть 2)
14. 14 Согласуем такой процесс работы, что: - заказчику оперативно демонстрируются промежуточные результаты для получения обратной связи - используется минимально необходимый набор рабочих процессов для концентрации на выполнении задач по разработке Практики KISS при организации процесса работы
15. 15 Здесь нужен «стартапер» История когда менеджер долго думал и разбирался с требованиями
16. 16 «Гюльчатай, открой личико» (приоритет на демонстрации результата(ов) заказчику) История как формировалось доверие у нового заказчика
17. 17 Давайте будем оптимистами (планируем по оптимистичным оценкам) История когда торопились сделать версию для выставки
18. 18 Процессы потом (минимальный оверхед на «бюрократию») История когда делали демо- приложение для нового продукта
19. 19 • Для планирования и организации процессов на начальном этапе нужен менеджер/лидер типа «стартапер». Иначе быстрый и небольшой проект рискует трансформироваться в длинный и большой либо, что случается более частно, завершится безрезультатно. • Первоочередное значение имеет возможность продемонстрировать воплощение идеи (концепта) представителям заказчика, чем качество результата для конечного пользователя. Практики KISS при организации процесса работы: итоги (часть 1)
20. 20 • В связи с этим имеет смысл предпочесть планирование работы по оптимистичным оценкам. • Какое-то время для работы по оптимистичным оценками можно найти за счет обеспечения минимального оверхеда на выполнение процессов со стороны команды. Да и в целом, новые процессы/инструкции/правила нужно внедрять по мере необходимости. Практики KISS при организации процесса работы: итоги (часть 2)
21. 21 В результате: 1. заказчик относительно быстро получает поставки продукта с новым функционалом 2. это позволяет ему быстро оценить результат работы (продукт) и предоставить обратную связь и 3. оценить взаимодействие (процесс) работы с командой (насколько он соответствует потребностям). Завершенный небольшой проект позволяет получить оценку «плацдарма» для дальнейшего развития продукта и/или сотрудничества, также стоит оценить дальнейшую применимость подхода на основе KISS Выводы
22. 22 Спасибо за внимание!