PMSAMARA - это самарское сообщество специалистов в управлении в сфере IT. Прийти и пообщаться с коллегами могут не только менеджеры проектов, но и менеджеры продуктов, аналитики, лидеры команд и просто "начальники отдела информатизации" всех мастей. Нам интересны мнения тех, с кем мы сообща добиваемся целей на работе.

четверг, 26 мая 2011 г.

Третья встреча

Третья встреча сообщества состоится в субботу 4 июня в 12.00 в ауд. 315, 1-го корпуса СГАУ по адресу Самара, ул. Молодогвардейская, 151.

Для тех кто уже забыл, где это, схема проезда – ниже :)

В связи с пропускным режимом СГАУ, просьба всем желающим принять участие – заблаговременно отправить свою заявку по e-mail: samarapmgroup@gmail.com

Тема встречи еще окончательно не определена. Так как Денис Тучин будет в отъезде на DevConf.ru, то тема посвященная рискам «Риски и способы их минимизации» откладывается до его возвращения, так как Денис хотел выступить с развернутым сообщением.

Предварительно, встреча будет :
«Как связаны оценки на QC и Аналитику?»

Если есть альтернативные предложения – пишите в комментарий.

Итак, схема проезда (обратите внимание! с уникального сервиса!):

четверг, 19 мая 2011 г.

Вторая встреча. Тема и пропуска.

Коллеги! Голосуем за тему второй встречи! Все, кто хочет принять участие, просьба написать письмо на samarapmgroup@gmail.com, чтобы не было проблем с пропускным режимом.

пятница, 13 мая 2011 г.

Вторая встреча

Вторая встреча сообщества (в формате круглого стола) планируется в воскресенье 22 мая, в 12.00. Встреча в офисе компании Mercury Development Russia по адресу: г. Самара, ул. Авроры 110, к.1. 2 этаж.


Прийти и пообщаться с коллегами могут все желающие менеджеры, руководители групп, владельцы продуктов, аналитики, а также сочувствующие :)

См. карту проезда ниже:
image
В случае, если предложенное время Вам не удобно – просьба сообщить об этом в комментариях. Если время будет неудобно большому количеству участников – возможен перенос встречи. Так что будьте активнее!

К обсуждению предлагаются следующие темы:
1. Работа с требованиями: как анализировать и прояснять
2. Риски и способы их минимизации
3. Как связаны оценки на QC и Аналитику?

Просьба голосовать за тему, которая Вам нравится, в комментариях. Если Вам интересна какая-либо другая тема – также предлагайте ее в комментариях.

Если кто-то хочет выступить с развернутым сообщением по любой из тем – welcome!

среда, 11 мая 2011 г.

Встреча на тему “Вопросы оценки «неосновных» работ в процессе разработки ПО”

Первая встреча Самарского сообщества менеджеров проектов состоялась 7 мая 2011 года. Во встрече было несколько приятных для меня моментов:

Мне было приятно что:

  1. встреча состоялась в офисе компании Меркдев, которую я люблю, потому что когда то работал в ней и это было замечательное время;
  2. собрались серьезные, но открытые люди с различным опытом;
  3. все явно были рады «дорваться до разговора»;
  4. я почти никого не знал лично;
  5. мне было интереснее слушать, чем говорить.

О чем же «наша» говорили? «Наша» говорили обо всем! Нет, тема конечно была, мы ее придерживались. Но, так как случились пункты 2 - 4, то постоянно всплывали сами собой смежные темы. Зачем нужны сообщества и профессиональные события, что такое продуктоводство, где брать кадры, как управлять качеством, кто такой “ПМ”. Но все таки «основной темой встречи были вопросы оценки „неосновных“ работ в процессе разработки ПО». Вопрос оказался сложным и однозначных рекомендаций выявили немного.

Тезисы такие:

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

В общем, дорвались. УлыбкаЭффект первой встречи и весна сделали разговор немного сумбурным, обо всем. Но зато всем есть о чем подумать и, кажется, все сказали, что хотели. По крайней мере, у всех был на то шанс.

Спасибо всем, кто пришел!

Копилка тем

В нашем блоге появилась копилка тем для обсуждения. Если у Вас есть тема, которую Вы хотите обсудить -- добавьте тему в комментарии на странице-копилке.

вторник, 10 мая 2011 г.

Первая встреча. Тезисы. 1ая часть


В субботу 7 мая 2011 года состоялась первая встреча Самарского сообщества менеджеров проектов.

Во встрече участвовали:
1. Александр Калугин (Mercury Development, pmarcor)
2. Константин Быченков (Открытый Код)
3. Дмитрий Мартышкин (Открытый Код)
4. Илья Красинский (Flexis)
5. Денис Журавлев (Indigo Byte Systems)
6. Константин Иванов (Mercury Development)
7. Александр Сергеев (CамараИнформСпутник)
8. Антон Катков (Flexis)
9. Денис Пушкин (Mercury Development)
10. Дмитрий Карягин (i-Sys)
11. Денис Тучин (i-Sys)
12. Антон Погодин (i-Sys)
13. Александр Смирнов (Mercury Development)
14. Алексей Литвишко (Mercury Development)

По мнению участников, необходимость в сообществе или
( «профсоюзе» :) ) самарских менеджеров проектов несомненно существует, и высказались за следующие основные формы работы сообщества:
1. Online blog.
2. Встречи в формате круглого стола для обсуждения конкретных вопросов и определенных жизненных ситуаций/кейсов.
3. Встречи в формате мини-конференций.
4. Встречи с приглашением экспертов и представителей других сообществ.

Также большинство участников высказались за сотрудничество с аналогичными сообществами на региональном и российском уровне.

Целями сообщества, с точки зрения большинства участников, должны быть:
1. Эффективное общение и обмен опытом и мнениями между менеджерами проектов в различных областях.
2. Обсуждение существующих процессов, достоинств, недостатков, проблем.
3. Обсуждение практических аспектов менеджмента, особенностей и подводных камней применения теория на практике.
4. Развитие «искусства» управления проектами в общем существующих общих проблем, best practices, собственной квалификации.
5. Распространение информации об эффективных методах управлении проектами.

Основной темой встречи были вопросы оценки «неосновных» работ в процессе разработки ПО.

Тезисы обсуждения находятся в процессе обработки и будут опубликованы в ближайшие дни.

суббота, 7 мая 2011 г.

Twitter

У сообщества появился твиттер @pmsamara
Теперь будем еще и твиттить новости.

Костя Быченков и Денис Пушкин вели репортаж с первой встречи с тегом #pmsamara