Блог

В любой сфере деятельности роль управляющего является ключевой. Особенно, когда этот человек не навязан высшим руководством (искусственный промоушен), а достиг достаточно высокого уровня личностного и профессионального развития собственными силами, и чью власть, авторитет и профессионализм признают по обе стороны баррикад — как участники проекта, так и клиенты.

Для каждой сферы деятельности, безусловно, существуют свои условия приобретения статуса /должности/ ПМа. к примеру, прорабом на стройке может быть только человек, который знает сколько нужно кирпичей, чтобы соорудить стену. И это знание строитель может получить только из практического опыта. Эту аналогию я всегда примеряла к сфере IT (web-development в частности), будучи уверенной, что ПМом может стать исключительно программист с огромным багажом практического опыта за плечами.

Вот определение этого понятия, выведенное мною:

Проект менеджер — это опытный «архитектор», который не занимается непосредственно написанием кода, а распределяет задачи между всеми участниками проекта, следит за соблюдением сроков реализации и объемов, своевременно и эффективно реагирует на обеспечение проекта необходимыми ресурсами, владеет навыками мотивации и стимуляции команды к эффективной работе. Он, также, выступает связующим звеном между клиентом/заказчиком и своей командой.

Из определения следует, что ПМ, в первую очередь, это человек с высокими организаторскими способностями. Хороший ПМ в IT-сфере может достичь такого же результата во многих не очень специфических (технологически или технически) сферах. Ведь главное здесь — понимание процессов и планирование, психологическая мотивация и энергичность, которая стимулирует и «заставляет» исполнителей проявлять полезную активность в ответ.

Кардинально изменилось мое мнение о профессиональных качествах и требования к ПМу в области веб-девелопмента именно тогда, когда я получила богатый и разносторонний опыт работая на этой должности в компании InternetDevels (кстати, не будучи программистом ни по образованию, ни по призванию).

На данном этапе у меня лично сформировалось 5 основных установок (принципов) для человека, который имеет желание взять на себя и нести полную ответственность за ведение проекта и его успешную реализацию.

1) Понять потребности клиента и донести эту входящую информацию до исполнителей, никак не исказив ее

Если вы сами не понимаете, чего хочет в результате заказчик, то как можно корректно поставить задачу ее исполнителям? Надо дойти до этого понимания, на этапе оценки бюджета или задачи, вкладывая как можно больше времени в общении с заказчиком и задавая уточняющие вопросы. Очень полезным методом здесь является составление структуры будущего сайта и его функционалов в документе, который можно показать заказчику, чтобы получить его подтверждение того факта, что мы правильно понимаем его требования. Также такой документ должен быть сформирован с учетом того, что на его основании будут ставиться задачи программистам: раздел Блоги не может быть реализован без страницы создания и страницы для вывода данного типа материала, например. Политика «программисты разберутся и без меня» не работает: девелоперы — это творческие люди, которые мыслят в своем, немного аморфном и недосягаемому для мировосприятию среднестатистического гуманитария, хотя любят исключительно четкую постановку задачи. Поэтому формулировка «сделайте, как в Вконтакте» необходимо разбирать на составляющие и требовать от клиента детализации по каждому из них.

2) Выяснять цели проекта, планировать этапы реализации проекта и распределять имеющиеся ресурсы между исполнителями

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

3) Занимать активную позицию

Это двусторонний процесс: заказчика необходимо постоянно держать в курсе событий и состояния реализации задач проекта, а исполнителей необходимо стимулировать к интеракции с клиентом посредством вас самих, для детализации постановки задач. Только при таком условии ваш клиент будет чувствовать себя в надежных руках. А команда тем более. Ведь общаясь (не только формально, но и в непринужденной ситуации) с участниками проекта можно получить много информации, а также стать катализатором взаимодействия в команде (тем более, когда она работает впервые в таком составе), что положительно отразится на эффективности ее работы в целом.

4) Быть отзывчивым к капризам клиента, но одновременно избегать запуска в разработку того, что ему действительно не нужно

В этом плане не стоит забывать, что мы не должны быть «индусами» (стереотип, который сложился у работников IT-сферы). Если заказчик просит сделать что-то бессмысленное, нелогичное и вовсе ненужное (исходя из первоначально поставленных целей проекта (см. п.1) мы уже можем формировать такие суждения), то лучше направить его в правильное русло. И задавая вопрос «Почему вы считаете, что для вас необходим этот функционал?», «Какова цель реализации этого функционала?», получить сведения, которые не будут противоречить изначально определенным целям проекта. Это поможет избежать возможных обвинений в сторону исполнителей типа: «Зачем вы потратили мои деньги на то, что мне не нужно?»

5) В случае возникновения конфликтной ситуации с заказчиком занимать позицию бесстрастного и объективного арбитра

Если клиент в силу тех или иных причин пытается обвинить команду в том, что «ничего не работает», «все слетело», «ваш сайт медленно работает» и т. п., необходимо добиться конкретики в формулировке проблемы. Как правило, после задания нескольких уточняющих вопросов, а также повторного инструктажа по пользованию сайтом, проблема сама по себе теряет суть и обвинения оказываются безосновательными.

Однако в том случае, когда проблема таки имеет место, следует подчеркнуть, что это обычный рабочий процесс и такие ситуации возможны и мы несем исключительную ответственность за ее устранение в кратчайшие сроки. Идти же на поводу «истерики» заказчика в первую очередь вредно тем, что обе стороны конфликта тратят тот драгоценный энергетический потенциал (по аналогии с бензином, которым заправляют машину), которым обеспечивается работоспособность и эффективность работы команды в целом.

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

Эта статья, очевидно, не является типичной для данного ресурса — как правило это узкоспециализированные блог-посты о реализованных возможностях в Drupal и т. п. Однако не стоит забывать, что и заказчики прежде всего люди, и код тоже пишут люди. А споры между обеими сторонами продолжаются, как правило, вокруг моральных качеств, идей и принципов, а никак не о том, правильно или нет использована функция в коде.

Join the conversation
0 Comments