Менеджер проекта

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

В инженерных дисциплинах цель команды - работающая система (и как следствие удовлетворённый клиент). Система должна работать эффективно, дёшево решать задачи клиента. Поэтому любые позиции внутри команды, которые эту цель отодвигают (личные амбиции, желание "прокачаться" вместо решения задач) - это плохо. Нужно создать атмосферу, когда всплывают идеи, как решить задачу проще, эффективнее, прозрачнее - это хорошо. Менеджер проекта должен это понимать.

Не тот человек в качестве менеджера проекта - большой риск. Человек для этой роли - достаточно уникальный, он должен совмещать в себе понимание технологий проектирования и понимание технологий управления.

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

  Подбор команды, организация её работы и мотивация

Что нужно учитывать при подборе команды?

• Образование. Конечно, бывают гениальные самоучки, но их число не велико. А системные знания - это основа основ.
• Опыт работы, проекты, роли в этих проектах. Практический опыт надо оценивать не только с точки зрения сложности задания, но и с точки зрения работы в команде.
• Владение технологиями.
• Возраст, мотивация.
• Лидерство.
• И в последнюю очередь - владение сертификатами Битрикс. Потому что обучение работе в рамках платформы Bitrix Framework - задача не сложная, если есть системные знания программирования и опыт работы.

В штате команды должен быть как минимум один качественный программист. Такой, у которого "горят" глаза при виде сложной задачи. Верстальщик, умеющий вставлять простенький PHP код - не программист. Такого достаточно для сайтов-визиток, для кастомизации шаблонов компонентов Bitrix Framework. Но для сложного и крупного проекта необходим программист с высокой квалификацией, серьёзным портфолио. В крайнем случае - с высшим образованием.

И чем сложнее проект, тем больше должно быть настоящих программистов. Это не означает, что в команде не может быть неопытных разработчиков. Такие могут выполнять несложные задачи, попутно совершенствуясь в собственном мастерстве. Обучение у опытных мастеров - лучший способ вырасти в профессионала.

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

Вопрос денежного стимула не прост. С одной стороны программист с "горящими глазами" может работать достаточно долго "за идею". Однако, "обиженный" программист работает не в полную меру, а "сильно обиженный" может представить даже угрозу при слабом контроле за качеством кода и его безопасностью.

С другой стороны, у каждого есть "внутренняя оценка" своих качеств и несоответствие этой оценке (в сторону завышения) только развращает сотрудников. Деньги должны быть достойными, но не лёгкими.

Один из серьёзных факторов риска - незнание продукта и предметной области проекта. С незнанием продукта, думается всё понятно. По предметной области должна быть возможность получить чёткую, конкретную и быструю консультацию к заказчика. Это должно быть оговорено с ним (и понято им) ещё на стадии переговоров.

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

  Инструменты коллективной работы

Правильно организованная коллективная работа обязательно предполагает использование IDE, баг-трекеров, систем накопления информации типа Wiki, других инструментов. Об этом в курсе есть отдельная глава.

  Знание предметной области заказа

Разработчик не должен разбираться в предметной области. Иначе ему некогда будет программировать. Разработчик должен иметь возможность получать ответы на свои вопросы в идеале - сразу, "по жизни" - в течение разумного времени. Получать конкретные ответы на конкретные вопросы.

Вот, например, фраза из ТЗ: «покупатель может принадлежать группе клиентов, получающих скидку». Вопросы, которые возникнут у программиста:

• Покупатель может входить в несколько групп?
• Как в этом случае рассчитывается скидка? Нужна формула.
• На какой срок покупатель включается в группу?
• При удалении покупателя из группы его уведомить? По e-mail или смс?
• и т.д, и т.п

Точные и формальные ответы на эти вопросы должны быть понятны разработчику перед началом работы. Эти ответы - зона ответственности менеджера проекта. Он должен сам давать ответы или найти того, кто ответит разработчику точно на возникающие вопросы по предметной области. Например, можно включить в проектную группу аналитика, эксперта или толкового представителя заказчика, который будет не спать ночами, пока в деталях не раскопает все тонкости и логику проектируемой системы. Или менеджер должен сам погрузиться в проект, предметную область и сделать эту работу сам.

Способ снижения рисков в ситуации с пониманием предметной области простой: проверьте цепочку формирования требований от менеджера, аналитика - к программисту.

1. Задайте менеджеру веб-проекта пару вопросов, уточняющих детали предметной области и если в ответ польется "вода", то примите меры по экстренной мотивации. Или замене менеджера.
2. Выясните насколько клиент, как эксперт в предметной области, участвует в процессе проектирования и уточнения требований. Или он ждет и грезит?
3. Поговорите с разработчиками — кто и как отвечает им на вопросы по предметной области, как четко и непротиворечиво? Им все понятно?

  Материалы по теме

• Как изучать Bitrix Framework? (учебный курс)
• Как подобрать разработчиков? (тема на форуме)