Дата последнего изменения: 14.02.2023
Эффективная работа команды над проектом зависит от нескольких факторов:
Менеджер проекта - не обязательно отдельная штатная должность в рамках студии, это скорее организатор процесса, в котором он участвует сам. В небольших студиях это может быть самый опытный программист или авторитетный член команды.
В инженерных дисциплинах цель команды - работающая система (и как следствие удовлетворённый клиент). Система должна работать эффективно, дёшево решать задачи клиента. Поэтому любые позиции внутри команды, которые эту цель отодвигают (личные амбиции, желание "прокачаться" вместо решения задач) - это плохо. Нужно создать атмосферу, когда всплывают идеи, как решить задачу проще, эффективнее, прозрачнее - это хорошо. Менеджер проекта должен это понимать.
Не тот человек в качестве менеджера проекта - большой риск. Человек для этой роли - достаточно уникальный, он должен совмещать в себе понимание технологий проектирования и понимание технологий управления.
В сложных проектах командой должен управлять менеджер-технолог, понимающий техническую суть проекта. Ни в коем случае вопросы бизнеса не должны влиять на процессы разработки. Задача перед программистами должна при этом ставиться так, чтобы у них "загорелись" глаза.
Что нужно учитывать при подборе команды?
В штате команды должен быть как минимум один качественный программист. Такой, у которого "горят" глаза при виде сложной задачи. Верстальщик, умеющий вставлять простенький PHP код - не программист. Такого достаточно для сайтов-визиток, для кастомизации шаблонов компонентов Bitrix Framework. Но для сложного и крупного проекта необходим программист с высокой квалификацией, серьёзным портфолио. В крайнем случае - с высшим образованием.
И чем сложнее проект, тем больше должно быть настоящих программистов. Это не означает, что в команде не может быть неопытных разработчиков. Такие могут выполнять несложные задачи, попутно совершенствуясь в собственном мастерстве. Обучение у опытных мастеров - лучший способ вырасти в профессионала.
Отдавайте предпочтение разработчикам имеющим хотя бы онлайновые сертификаты о прохождении курсов. К сожалению, разработчики не знакомые с архитектурой и технологиями Bitrix Framework пишут неоптимальный код.
Разработчик должен уметь смотреть на систему глазами клиента и менеджера, знать административную и публичную части.Однако у программистов всегда есть соблазн залезть в "высшие материи". Попробовать технологии, которые он ещё не использовал. И в этой ситуации может возникнуть "вилка" между желаниями и возможностями. Не забывая про свободу программистов нужно постоянно держать в уме то, что проектирование должно быть проведено адекватно поставленной технической цели, разработка должна быть простой, надёжной и расширяемой. Менеджер-бизнесмен в ситуации сложного, высоконагруженного проекта может не справиться с этой задачей.
Вопрос денежного стимула не прост. С одной стороны программист с "горящими глазами" может работать достаточно долго "за идею". Однако, "обиженный" программист работает не в полную меру, а "сильно обиженный" может представить даже угрозу при слабом контроле за качеством кода и его безопасностью.
С другой стороны, у каждого есть "внутренняя оценка" своих качеств и несоответствие этой оценке (в сторону завышения) только развращает сотрудников. Деньги должны быть достойными, но не лёгкими.
Один из серьёзных факторов риска - незнание продукта и предметной области проекта. С незнанием продукта, думается всё понятно. По предметной области должна быть возможность получить чёткую, конкретную и быструю консультацию к заказчика. Это должно быть оговорено с ним (и понято им) ещё на стадии переговоров.
Другой фактор риска - недисциплинированность программистов. Она вызвана разными причинами: от незнания продукта через обычную невнимательность, до чрезмерного увлечения новыми технологиями.
Правильно организованная коллективная работа обязательно предполагает использование IDE, баг-трекеров, систем накопления информации типа Wiki, других инструментов. Об этом в курсе есть отдельная глава.
Разработчик не должен разбираться в предметной области. Иначе ему некогда будет программировать. Разработчик должен иметь возможность получать ответы на свои вопросы в идеале - сразу, "по жизни" - в течение разумного времени. Получать конкретные ответы на конкретные вопросы.
Вот, например, фраза из ТЗ: «покупатель может принадлежать группе клиентов, получающих скидку». Вопросы, которые возникнут у программиста:
Точные и формальные ответы на эти вопросы должны быть понятны разработчику перед началом работы. Эти ответы - зона ответственности менеджера проекта. Он должен сам давать ответы или найти того, кто ответит разработчику точно на возникающие вопросы по предметной области. Например, можно включить в проектную группу аналитика, эксперта или толкового представителя заказчика, который будет не спать ночами, пока в деталях не раскопает все тонкости и логику проектируемой системы. Или менеджер должен сам погрузиться в проект, предметную область и сделать эту работу сам.
Способ снижения рисков в ситуации с пониманием предметной области простой: проверьте цепочку формирования требований от менеджера, аналитика - к программисту.