Первая встреча Самарского сообщества менеджеров проектов состоялась 7 мая 2011 года. Во встрече было несколько приятных для меня моментов:
Мне было приятно что:
- встреча состоялась в офисе компании Меркдев, которую я люблю, потому что когда то работал в ней и это было замечательное время;
- собрались серьезные, но открытые люди с различным опытом;
- все явно были рады «дорваться до разговора»;
- я почти никого не знал лично;
- мне было интереснее слушать, чем говорить.
О чем же «наша» говорили? «Наша» говорили обо всем! Нет, тема конечно была, мы ее придерживались. Но, так как случились пункты
Тезисы такие:
- Что считать «основными работами»? Договорились, что основное — это написание кода. Довольно наивно, но надо было о чем то договориться, чтоб продолжить.
- Оценка проекта должна обсуждаться с руководством бизнеса. Потому что стоимость проекта влияет на стоимость бизнеса в течении довольно большого промежутка времени. Оценка проекта, процесс, к которому надо возвращаться время от времени в течении проекта.
- Внезапно, обсудили что такое QA и чем он отличается от QC. Причем 2 раза. Попутно, выяснили, что принято на высоком уровне закладывать стоимость QA в объеме 30% от стоимости разработки. А если надо детально — то надо смотреть в какой обстановке будем работать и привлекать сам QA. И вообще, к оценке надо привлекать исполнителей (если они есть!).
- На оценку QC влияет характер результата проекта (мобильное приложение, корпоративная система или что), состава команды, количества итераций, окружения проекта. На выходе оценка в часах. Ну правда некоторые считали, что количество итераций не так важно и оценка QC зависит в первую очередь от квалификации команды.
- Чем лучше вы обсудите на этапе пресейла будущий результат с заказчиком, тем лучше оцените. Рисуйте экраны, описывайте логику и “фичи”, объясните заказчику как вы решите его бизнес-задачи, если есть на это время. И тут опять мы утыкаемся в особенности бизнеса, у кого то месяц на пресейл, у кого то два дня.
- Оценка в количестве user-stories – зачастую лукавство, потому что на практике тут много важных деталей и мало контроля со стороны заказчика (тут мы плавно ушли от стоимости проекта к стоимости контракта и до конца встречи никто этого не заметил).
- Работу менеджера проекта заранее оценить невозможно. Можно только оценить, нужен выделенный менеджер или нет.
- Жесткие требования увеличивают стоимость. Потому что достичь точных количественных требований, или функциональных требования в жесткой форме (сервис переживет 1 000 000 визитов в час) то заказчик ужаснется цене. И лучше удержать заказчика от жестких требований, так как он все равно часто не понимает, что ему нужно. Исключение – если вы продаете решение, заточенное на какую-то нишу. Но все таки, мы думаем за заказчика, но не принимаем за него решения, так что если он все таки хочет, то придется соглашаться с его требованиями.
- Похоже, что качество – это наша наиболее общая проблема, от которой лихорадит стоимость проекта, потому что все постоянно возвращались к вопросу “от чего зависит качество?”.
- Стоимость проекта это стоимость разработки + качества + гарантии + инфраструктура и “фейки” + коммуникации + обучение пользователей + развертывание + документирование.
- Риски лучше все таки выносить и явно показывать заказчику. Тогда можно будет обсудить минимизацию рисков и на самом деле будет дешевле. Обсуждение рисков – начало аналитической работы.
В общем, дорвались. 
Эффект первой встречи и весна сделали разговор немного сумбурным, обо всем. Но зато всем есть о чем подумать и, кажется, все сказали, что хотели. По крайней мере, у всех был на то шанс.
Спасибо всем, кто пришел!
Комментариев нет:
Отправить комментарий