На данном этапе у меня лично сформировалось 5 основных установок (принципов) для человека, который имеет желание взять на себя и нести полную ответственность за ведение проекта и его успешную реализацию.
1) Понять потребности клиента и донести эту входящую информацию до исполнителей, никак не исказив ее
Если вы сами не понимаете, чего хочет в результате заказчик, то как можно корректно поставить задачу ее исполнителям? Надо дойти до этого понимания, на этапе оценки бюджета или задачи, вкладывая как можно больше времени в общении с заказчиком и задавая уточняющие вопросы. Очень полезным методом здесь является составление структуры будущего сайта и его функционалов в документе, который можно показать заказчику, чтобы получить его подтверждение того факта, что мы правильно понимаем его требования. Также такой документ должен быть сформирован с учетом того, что на его основании будут ставиться задачи программистам: раздел Блоги не может быть реализован без страницы создания и страницы для вывода данного типа материала, например. Политика «программисты разберутся и без меня» не работает: девелоперы — это творческие люди, которые мыслят в своем, немного аморфном и недосягаемому для мировосприятию среднестатистического гуманитария, хотя любят исключительно четкую постановку задачи. Поэтому формулировка «сделайте, как в Вконтакте» необходимо разбирать на составляющие и требовать от клиента детализации по каждому из них.
2) Выяснять цели проекта, планировать этапы реализации проекта и распределять имеющиеся ресурсы между исполнителями
На этапе запуска проекта часто применяется практика разбивки его на «релизы». Ведь прогнозирование сроков реализации большого количества взаимосвязанных функционалов на короткой дистанции имеет меньшую погрешность, соответственно, и уменьшает риски неадекватной оценки сроков реализации. А это, само собой, предотвращает возникновение возможных конфликтов в силу несовпадения ожиданий заказчика с реалиями.
3) Занимать активную позицию
Это двусторонний процесс: заказчика необходимо постоянно держать в курсе событий и состояния реализации задач проекта, а исполнителей необходимо стимулировать к интеракции с клиентом посредством вас самих, для детализации постановки задач. Только при таком условии ваш клиент будет чувствовать себя в надежных руках. А команда тем более. Ведь общаясь (не только формально, но и в непринужденной ситуации) с участниками проекта можно получить много информации, а также стать катализатором взаимодействия в команде (тем более, когда она работает впервые в таком составе), что положительно отразится на эффективности ее работы в целом.
4) Быть отзывчивым к капризам клиента, но одновременно избегать запуска в разработку того, что ему действительно не нужно
В этом плане не стоит забывать, что мы не должны быть «индусами» (стереотип, который сложился у работников IT-сферы). Если заказчик просит сделать что-то бессмысленное, нелогичное и вовсе ненужное (исходя из первоначально поставленных целей проекта (см. п.1) мы уже можем формировать такие суждения), то лучше направить его в правильное русло. И задавая вопрос «Почему вы считаете, что для вас необходим этот функционал?», «Какова цель реализации этого функционала?», получить сведения, которые не будут противоречить изначально определенным целям проекта. Это поможет избежать возможных обвинений в сторону исполнителей типа: «Зачем вы потратили мои деньги на то, что мне не нужно?»
5) В случае возникновения конфликтной ситуации с заказчиком занимать позицию бесстрастного и объективного арбитра
Если клиент в силу тех или иных причин пытается обвинить команду в том, что «ничего не работает», «все слетело», «ваш сайт медленно работает» и т. п., необходимо добиться конкретики в формулировке проблемы. Как правило, после задания нескольких уточняющих вопросов, а также повторного инструктажа по пользованию сайтом, проблема сама по себе теряет суть и обвинения оказываются безосновательными.
Однако в том случае, когда проблема таки имеет место, следует подчеркнуть, что это обычный рабочий процесс и такие ситуации возможны и мы несем исключительную ответственность за ее устранение в кратчайшие сроки. Идти же на поводу «истерики» заказчика в первую очередь вредно тем, что обе стороны конфликта тратят тот драгоценный энергетический потенциал (по аналогии с бензином, которым заправляют машину), которым обеспечивается работоспособность и эффективность работы команды в целом.
Исходя из выше изложенного убедительно звучит следующий вывод: для эффективного управления проектами в области веб-девелопмента не важно имеет ли человек опыт в программировании. Важны человеческие качества, прежде всего. Но «подкованность» в специализированных знаниях станет только всем на помощь.
Эта статья, очевидно, не является типичной для данного ресурса — как правило это узкоспециализированные блог-посты о реализованных возможностях в Drupal и т. п. Однако не стоит забывать, что и заказчики прежде всего люди, и код тоже пишут люди. А споры между обеими сторонами продолжаются, как правило, вокруг моральных качеств, идей и принципов, а никак не о том, правильно или нет использована функция в коде.
