Седьмая встреча. Тезисы

Несколько запоздалые тезисы седьмой встречи.

Тема: Координация между проектами

Присутствовали: Анастасия Печкурова (Parcsis), Зиннур Темербеков (Parcsis), Александра Туманова (Parcsis), Денис Тучин (i-Sys), Денис Слюсарь, Елена Тимбай (СамараИнформСпутник), Алексей Хренов (ЛАНИТ-Самара), Алина Айсувакова (Parcsis), Игорь Кузнецов (Parcsis), Костя Иванов (Mercury Development), Дмитрий Карягин (i-Sys), Денис Журавлев (Indigo Byte), Александр Калугин (Mercury Development, PMarcor), Андрей Чернов (СамараИнформСпутник), Александр Сергеев (СамараИнформСпутник), Александр Кушпель (студия Dominion).

В первой части встречи, Настя и Зиннур рассказали о «взрыве» Parcsis и об их методологии Le Cirque.

Презентация доклада доступна здесь:
http://pmarcor.com/wp-content/uploads/2011/09/PMSAMARA-Presentation-Parcsis-20110903.pdf


Тезисы:

1. Цитата: В больших проектах со временем появляется большое количествео неявных знаний. И мы начали факапить... А потом начали использовать Wiki для протоколирования основных моментов.

2. Цитата: Мы думали, что это табличка будет временной, пока мы не реализуем свой трэкер. Но трекер мы всё еще рисуем, так как появляются новые задачи – а табличка в Google Docs живет...

3. Цитата: При распределении ресурсов, выигрывает самый занудный менеджер.

4. Цитата: У нас есть жесткое правило: не спрашивать у программиста, когда он освободится от своей задачи, так как он скорее всего понятия не имеет...

5. Идея: Dashboard – таблица с еженедельным статусом выполнения корневых задач по различным проектам, безотносительно исполнителей. Цель: с учетом текущих задач и статусов расставлять приоритеты проектов.

6. В Dashboard c информацией с еженедельным статусом проектов– не следует отслеживать интегральную оценку по проекту. Этот инструмент предназначен именно для приоретизации здесь и сейчас.

7. В DashBoard – должны попадать именно «рутовые» (корневые, крупные) задачи проектов чтобы можно было планировать на высоком уровне. Детальная разбивка по задачам для планирования не нужна.

8. DashBoard заполняется примерно на итерацию в глубину (то есть горизонт планирования примерно 4 недели), причем заполняется полностью обычно на второй недели итерации.

9. Идея: Для наглядности при распределении задач большого количества проектов по исполнителям имеет смысл группировать проекты, которыми занимается один менеджер в «мега-проекты».

10. Цитата: В таблице распределения задач по исполнителям имеет смысл указывать все квалификации исполнителей. Это, в том числе, помогает новым менеджерам познакомиться со своей командой :)

11. Идея: Если в таблице распределения задач по исполнителям запланирована задача через два дня для конкретного программиста - можно легко проверить в JIRA, всё ли готово к этой задаче, корректно ли она сформулирована и т д – что позволяет также избегать простоев в связи с некорректной постановкой задачи.

12. Идея: Обучение новичков – бразильская система: (а) 20 минут в гугле перед тем как задать вопрос, (б) не спрашивай как, а предложи несколько вариантов решения, (в) в рамках своей квалификации – принимаешь решения и несешь за них ответственность; лид может помочь тебе только выявить достоинства и недостатки возможных альтернатив; (г) ежедневный контроль выполнения тасков.

13. Цитата: Копилка – если хочешь задать мне вопрос, положи денежку :)

14. Цитата: Срочных задач не бывает. Мы не бросает всё, чтобы релизовать запрос, за исключением двух случаев: при выпуске и в критических ситуациях (пример - сервер лежит).

15. Цитата: Мы стараемся не переключать программиста между проектами в течение дня – что дает прирост в производительности. Однако мы вынуждены давать задачи из нескольких проектов в рамках одного техническим дизайнерам.

16. Цитата: Каждая корневая задача состоит минимум из 4-х подзадач: задача на аналитика, дизайнера, фронт-енд разработчика, бэк-энд разработчика. Но вообще, зависит от этапа проекта

17. Вопрос: отслеживаете ли вы разниц планируемой загрузки и фактической? Ответ: Пока нет, особо не интересно...

18. Идея: релиз с частичной функциональностью и апдейт через несколько дней.

19. Вопрос: на внешние проекты, назначается ли менеджер сразу, либо происходит сначала некоторая высокоуровневая прикидка высшим руководством?
Ответ:
a. Сначала подготавливаем "паспорт проекта"
Основная задача на этом этапе -- получить готовый документ -- "паспорт
проекта", в котором все ключевые участники проекта согласуют свой этап
работ по объему и срокам. Документ является отправной точкой для
любого проекта, некоторые компоненты как юридическая структура или
конкретное оборудование могут решаться в течении проекта и не требуют
обязательной реализации до начала проекта.
Обшая концепция проекта - участвуют овнер, дизайнер, тех.директор
Верхнеуровневые требования - участвуют овнер, дизайнер, тех.директор
Верхнеуровневая оценка трудозатрат - участвиуют тех.директор,
дизайнер; овнер в меньшей степени.
Верхнеуровневый тайминг проекта - участвиуют тех.директор, дизайнер;
овнер в меньшей степени
Финансовая модель - финансовый директор, овнер
Бюджет - финансовый директор, овнер
Требования к оборудованию - тех.директор, финансовый директор
Юридическая структура - финансовый директор, овнер
b. Вот после этого назначается менеджер, готовится бэклог и поооехали :)

20. Вопрос: кто разрабатывает архитектуру? Сами программисты? Ответ: зависит от состава команды и уровня квалификации участников.

21. Вопрос: при переключении между проектами, вы стараетесь переключить всю команду целиком, или переформируете команду? Ответ: Стараемся достичь баланса, чтобы организовать обмен знаниями между различными командами и в то же время дать возможность поиграть в сработанной команде. Фактически одна сработанная команда работает в рамках только одного проекта в ед времени. Дергаем сильных ребят на время в другие команды – для передачи знаний.

22. Вопрос: Как организуются задачи по передаче знаний? Ответ: Рассматриваем такие задачи в рамках проекта которому не хватает знаний. Обычно сильный специалист подключается к проекту 2x0.5 дня в неделю.

22. Вопрос: Как решается проблема поддержки? Если инженера отключили от проекта, кто потом за ним фиксит баги? Ответ: В зависимости от бага. Стараемся компоновать баги в блоки и выделять программиста на короткое время для фиксов.

23. Вопрос: Спрашиваете ли вы у сотрудников, вне зависимости от квалификации оценки трудоемкости различных задач. Ответ: да, причем дважды: при оценке бэклога на итерацию и в начале недели, на которую конкретная задача назначена.

24. Вопрос: Есть ли формальные процессы ревью? Ответ: раз в день просматриваются коммиты лидом а также перекрестное между девелоперами.

25. Цитата: при приеме мы учитываем природное любопытство: разобраться в новом быстро.

26. Вопрос: В какой момент и кем принимаются решения о документировании определенных технических находок в различных проектах? Документируются ли они? Ответ: формальных процессов нет, информация стекается к техническому директору.

27. Вопрос: Как часто и по какому поводу отвлекают программиста вопросами? Ответ: жестких правил нет, по ситуации. В случае если становится проблемой – то просто регламентируем время, или одну точку входа и т. д. Второй ответ: стараемся решать вопросы в рамках ежедневных совещаний или планируем короткие митинги заранее.

28. Вопрос модератору: нужно ли ежедневное совещание, это же очень дорогостояще. Ответ модератора: да, но оно должно быть жестко регламентировано по времени. Цель совещания – выявить проблемы на ранней стадии, если они есть.

29. Вопрос модератору: хорошо или плохо групповой чат? Ответ модератора: скорее плохо, так как написав в групповой чат о проблеме – инженер с себя снимает ответственность. А увидел ли кто-либо такое сообщение – непонятно. Плюс группового чата – протоколирование технических решений.

30. Вопрос модератору: кто должен присутствовать на совещании с командой? Только ПМ? Или еще ресурс менеджер, линейный менеджер, начальник ПМ-а? Ответ модератора:кто угодно, но ведет совещание – ПМ, и он там главный. Все вопросы других руководителей к ПМ-у решаются после совещания.

31. Вопрос: ваш процесс это самостоятельная разработка или внедрение чего-то. Ответ: Самостоятельно вырастили.

32. Вопрос: в связи с чем выбрана JIRA? Ответ: исторически так сложилось, от балды. Нам не хватает планировщика параллельных задач.

33. Вопрос: есть база знаний, что и насколько подробно туда пишется? Насколько база знаний помогает? Ответ: Часто задаваемые вопросы и архитектурные высокоуровневые проблемы. Конвеншны, мтодологии. Помогает сильно.