Введение.
Вот уже 5 лет я занимаюсь веб — разработками. За это время приходилось и на коленке делать сайты за несколько сотен долларов и участвовать в довольно крупных проектах. За последний год меня не оставляет ощущение deja vu. Где-то я уже видел: нервных заказчиков, взбешенных менеджеров, заваленных работой разработчиков и сорванные сроки. При этом для меня ничего не изменилось. Были все те же нечеткие, постоянно изменяющиеся требования, прессинг, и ни одного проекта, сданного в срок…
И это, не смотря на то, что “грабли” были всегда одни и те же.
Здесь я попробую описать наиболее частые проблемы в управлении веб-проектами, которые мне приходилось наблюдать. Вероятно, многое из сказанного ниже, можно отнести и к разработке программного обеспечения в целом. Однако мой скромный опыт в серьезных софтверных проектах не позволит мне провести подобное обобщение. Так же хотелось бы отметить, что во всех проектах я выступал в роли разработчика.
Итак.
Общее отношение:
Большинство моих знакомых менеджеров веб-проектов выросло из разработчиков. При этом частенько возникает ряд проблем.
Не у всякого исполнителя есть нацеленность на результат. Порой, работа воспринимается как процесс. Тогда как, у менеджера, как мне кажется, должна присутствовать личная заинтересованность в своевременной сдаче проекта. И это должно заключаться не столько в получении процентов, сколько в определенном настрое, мировоззрении.
Чрезмерный интерес к реализации. То есть вместо управленческих функций, менеджер начинает диктовать правила написания кода или формирования архитектуры.
Помню случай, когда разработчика повысили до ПМ. Через некоторое время, он заглянул в код, управляемого им проекта, и ужаснулся. “Если хочешь, чтобы что-то было сделано хорошо – сделай это сам” — сказал он и взялся за кодирование. При этом он был и остается отличным специалистом. Возможно, это была его личная неудача, так как когда ПМ начинает заниматься кодом, то отвлекается и теряет контроль над проектом.
Характер человека так же играет немаловажную роль. Я имею в виду готовность принимать решения и нести за них ответственность. Довольно часто можно встретить ситуацию, когда проблемы возникают из-за не сделанного в нужное время телефонного звонка или из-за неотправленного письма.
Стоит отметить и общее отношение к ошибкам. Бывает и так, что из-за страха перед начальством некоторые проблемы остаются не озвученными. Что через некоторое время может привести к более серьезным последствиям, чем, если бы проблема была решена на ранней стадии. (Рефлекс «сгребания мусора под ковер», не заметили — ну и ладно.)
И самый тяжелый случай: “Менеджеры меня гоняли, теперь уж погоняю я”.
То есть речь не идет об управлении, а скорее о самоутверждении. При этом забывается, что основная задача менеджера это не гонять сотрудников, а создать людям условия для работы и контролировать процесс (чтобы в заданные сроки, за заданный бюджет была реализована данная функциональность). Недостаточный контроль – так же частая проблема. Особенно, если ПМ был ответственным исполнителем.
Очень тяжело бывает работать с руководителями, которые считают, что люди – это ресурс. И это притом, что и менеджеры, и разработчики все те же наемные работники, просто у них различные роли в проекте.
Сроки
Наверное, одна из самых больных тем. Иногда складывается ощущение, что ПМ живут в каком-то своем мире. Понятно, что рынок веб — девелопмента насыщен. И за каждого клиента приходится биться, придумывая и сроки поменьше и цены пониже. При этом для меня остается загадкой, зачем раз за разом вводить команду разработки в состоянии аврала еще на самом начальном этапе работ.
Иногда встречается и другой подход. Сроки выполнения задач уточняются у исполнителей. Однако об адекватности подобных оценок мало кто задумывается.
И, как показывает практика, трудоемкость может быть недооценена, в лучшем случае на четверть.
Бывает и так, что сроки навязываются заказчиком. Это не такой уж и плохой вариант как кажется. Но только при том условии, если заказчик готов согласовать объем работ и принять бюджет (или же наоборот).
Отсутствие плана проекта
Конечно же, план есть. Только в голове менеджера и то расплывчато. Хотя, обычно это совсем не план, а общее понимание необходимых работ для завершения проекта. Мне кажется, что в управлении проектами основная задача – это создание предсказуемости. Что к данному моменту времени можно с высокой вероятностью назвать выполненный (и не выполненный) объем работ. В случае экстренных ситуаций план может помочь определить текущее состояние проекта, быстрее сориентироваться, и принять верное решение. Наличие плана дает еще один бонус в качестве возможности контроля над ходом работ.
Управление требованиями
Как мне кажется, любой проект должен начинаться со сбора и анализа требований. Как иначе понять, что действительно нужно клиенту? Проблема в том, что не всякий заказчик четко понимает, что именно он хочет от данного проекта. При создании сайтов это довольно распространенная ситуация. Среди разработчиков одно время даже ходила шутка: “Приходит к нам на днях один менеджер и говорит: Сделайте мне сайт”. В подобной ситуации есть два основных решения.
Первое – провести переговоры, и определить реальные требования и желаемый результат от создания проекта. Да, это не всегда просто. Порой одних переговоров может быть не достаточно. Однако с подобным подходом повышается вероятность, что заказчик получит действительно то, на что он хотел потратить свои деньги.
Второе решение более популярно. Основано оно на установке “Мы знаем, что Вам нужно”. При выборе данного подхода продается продукт, составленный из готовых модулей. Для веб – разработок, пожалуй, это довольно важно. Действительно, регулярное создание сайтов “с нуля” (если такое вообще возможно при большом потоке заказов) – это излишнее расточительство ресурсов. Но в таком случае, заказчику навязывается ряд ограничений, имеющихся у данного готового продукта. Соответственно чаще возникает ситуация, когда проект готов, а заказчик говорит: “Но получилось совсем не то, что мы хотели”.
Кроме того, отдельного внимания заслуживает сам процесс сбора требований. Обычно, это происходит бессистемно. То есть требования оседают то в памяти менеджера, то в электронной почте, то в логах ICQ. При этом контролировать их поток если не невозможно, то крайне сложно. Добавим к тому требования, озвученные по телефону, и получим следующие проблемы:
Управление рисками.
Ни в одном веб – проекте я не наблюдал полноценного управления рисками. Понятно, что они, в общем-то, одни и те же: неадекватная оценка объема работ и сроков, задержки при согласовании ТЗ или макетов, несвоевременное предоставление оборудования и так далее. Тем более непонятно, почему раз за разом, наступая на одни и те же грабли, эти риски игнорируются. Когда достаточно просто указать соответствующий пункт в договоре (если он конечно же есть).
Да, подобными оговорками можно испугать рядового клиента, который сбежит к конкуренту только потому, что “эти ребята сделают все быстро и без лишних заморочек”.
Это тоже риск. А регулярно сорванные сроки – это не риск испортить репутацию?
Совещания
Проведение совещаний по веб — проекту – довольно большая редкость. Во всяком случае, если они и проводятся, то подготовить и заблаговременно разослать повестку обычно забывают. Естественно, что с таким подходом, про составление протокола вообще речи не идет. Сами же совещания частенько сводятся к парным обсуждениям технических вопросов. В итоге, получается пустая трата времени: что обсуждали – не понятно, какие решения приняты – никто не запомнил, что дальше делать – тоже не ясно.
Работа над ошибками
Мало кто из моих знакомых ПМ` ов смог назвать мне количество проектов, в которых он участвовал. Проблема даже не столько в плохой памяти. Сколько в том, что результаты проекта мало кто анализирует. В процессе написания данной статьи, я даже провел опрос, интереса ради. На момент публикации лидирующим было мнение “Отмечаю в уме, но не документирую” – 25.32%. Причем из того же голосования видно, что только 35% процентов опрошенных проводит полноценный анализ проекта.
Получается, что опыт ведения проектов не накапливается. Так как при отсутствии привычки составлять соответствующие документы, с менеджерами из компании будут уходить и их знания, которыми не всегда можно поделиться при сдаче-приеме дел. Соответственно, процесс развития в управлении может двигаться крайне медленно.
Итого:
Возможно, основная проблема веб – девелопмента в незрелости. В этой сфере очень много молодых специалистов без опыта или специального образования. Многие, получив этот самый начальный опыт, переходят к более серьезным софтверным проектам, освобождая место новичкам.
Иногда возникает вопрос, а целесообразно ли усложнять процесс разработки сайтов, внедряя серьезный менеджмент проектов. Можно встретить убеждение – “Не думай как лучше, просто сделай этот сайт. Будет следующий проект – там сделаешь все по-уму.” Целесообразно, если это позволит выдавать более качественный продукт за меньшее время. Что, соответственно, приведет к снижению расходов. Плюс к тому — бонус в качестве более спокойной, предсказуемой работы – а это, как мне кажется, один из ключей к снижению текучести кадров.
А может быть, дело и в том, что заказчики еще не готовы платить по нескольку десятков (сотен) тысяч долларов за качественную разработку. И правда, зачем, если знакомые студенты сделают ту же работу, только за тысячу — полторы…
Не смотря на это, все чаще можно встретить технические задания на создание сайта, использование User Stories для подготовки к проектированию, итеративный подход при разработке… Мне кажется, это хороший знак, что развитие идет в правильном направлении.
Оригинал здесь
Вот уже 5 лет я занимаюсь веб — разработками. За это время приходилось и на коленке делать сайты за несколько сотен долларов и участвовать в довольно крупных проектах. За последний год меня не оставляет ощущение deja vu. Где-то я уже видел: нервных заказчиков, взбешенных менеджеров, заваленных работой разработчиков и сорванные сроки. При этом для меня ничего не изменилось. Были все те же нечеткие, постоянно изменяющиеся требования, прессинг, и ни одного проекта, сданного в срок…
И это, не смотря на то, что “грабли” были всегда одни и те же.
Здесь я попробую описать наиболее частые проблемы в управлении веб-проектами, которые мне приходилось наблюдать. Вероятно, многое из сказанного ниже, можно отнести и к разработке программного обеспечения в целом. Однако мой скромный опыт в серьезных софтверных проектах не позволит мне провести подобное обобщение. Так же хотелось бы отметить, что во всех проектах я выступал в роли разработчика.
Итак.
Общее отношение:
Большинство моих знакомых менеджеров веб-проектов выросло из разработчиков. При этом частенько возникает ряд проблем.
Не у всякого исполнителя есть нацеленность на результат. Порой, работа воспринимается как процесс. Тогда как, у менеджера, как мне кажется, должна присутствовать личная заинтересованность в своевременной сдаче проекта. И это должно заключаться не столько в получении процентов, сколько в определенном настрое, мировоззрении.
Чрезмерный интерес к реализации. То есть вместо управленческих функций, менеджер начинает диктовать правила написания кода или формирования архитектуры.
Помню случай, когда разработчика повысили до ПМ. Через некоторое время, он заглянул в код, управляемого им проекта, и ужаснулся. “Если хочешь, чтобы что-то было сделано хорошо – сделай это сам” — сказал он и взялся за кодирование. При этом он был и остается отличным специалистом. Возможно, это была его личная неудача, так как когда ПМ начинает заниматься кодом, то отвлекается и теряет контроль над проектом.
Характер человека так же играет немаловажную роль. Я имею в виду готовность принимать решения и нести за них ответственность. Довольно часто можно встретить ситуацию, когда проблемы возникают из-за не сделанного в нужное время телефонного звонка или из-за неотправленного письма.
Стоит отметить и общее отношение к ошибкам. Бывает и так, что из-за страха перед начальством некоторые проблемы остаются не озвученными. Что через некоторое время может привести к более серьезным последствиям, чем, если бы проблема была решена на ранней стадии. (Рефлекс «сгребания мусора под ковер», не заметили — ну и ладно.)
И самый тяжелый случай: “Менеджеры меня гоняли, теперь уж погоняю я”.
То есть речь не идет об управлении, а скорее о самоутверждении. При этом забывается, что основная задача менеджера это не гонять сотрудников, а создать людям условия для работы и контролировать процесс (чтобы в заданные сроки, за заданный бюджет была реализована данная функциональность). Недостаточный контроль – так же частая проблема. Особенно, если ПМ был ответственным исполнителем.
Очень тяжело бывает работать с руководителями, которые считают, что люди – это ресурс. И это притом, что и менеджеры, и разработчики все те же наемные работники, просто у них различные роли в проекте.
Сроки
Наверное, одна из самых больных тем. Иногда складывается ощущение, что ПМ живут в каком-то своем мире. Понятно, что рынок веб — девелопмента насыщен. И за каждого клиента приходится биться, придумывая и сроки поменьше и цены пониже. При этом для меня остается загадкой, зачем раз за разом вводить команду разработки в состоянии аврала еще на самом начальном этапе работ.
Иногда встречается и другой подход. Сроки выполнения задач уточняются у исполнителей. Однако об адекватности подобных оценок мало кто задумывается.
И, как показывает практика, трудоемкость может быть недооценена, в лучшем случае на четверть.
Бывает и так, что сроки навязываются заказчиком. Это не такой уж и плохой вариант как кажется. Но только при том условии, если заказчик готов согласовать объем работ и принять бюджет (или же наоборот).
Отсутствие плана проекта
Конечно же, план есть. Только в голове менеджера и то расплывчато. Хотя, обычно это совсем не план, а общее понимание необходимых работ для завершения проекта. Мне кажется, что в управлении проектами основная задача – это создание предсказуемости. Что к данному моменту времени можно с высокой вероятностью назвать выполненный (и не выполненный) объем работ. В случае экстренных ситуаций план может помочь определить текущее состояние проекта, быстрее сориентироваться, и принять верное решение. Наличие плана дает еще один бонус в качестве возможности контроля над ходом работ.
Управление требованиями
Как мне кажется, любой проект должен начинаться со сбора и анализа требований. Как иначе понять, что действительно нужно клиенту? Проблема в том, что не всякий заказчик четко понимает, что именно он хочет от данного проекта. При создании сайтов это довольно распространенная ситуация. Среди разработчиков одно время даже ходила шутка: “Приходит к нам на днях один менеджер и говорит: Сделайте мне сайт”. В подобной ситуации есть два основных решения.
Первое – провести переговоры, и определить реальные требования и желаемый результат от создания проекта. Да, это не всегда просто. Порой одних переговоров может быть не достаточно. Однако с подобным подходом повышается вероятность, что заказчик получит действительно то, на что он хотел потратить свои деньги.
Второе решение более популярно. Основано оно на установке “Мы знаем, что Вам нужно”. При выборе данного подхода продается продукт, составленный из готовых модулей. Для веб – разработок, пожалуй, это довольно важно. Действительно, регулярное создание сайтов “с нуля” (если такое вообще возможно при большом потоке заказов) – это излишнее расточительство ресурсов. Но в таком случае, заказчику навязывается ряд ограничений, имеющихся у данного готового продукта. Соответственно чаще возникает ситуация, когда проект готов, а заказчик говорит: “Но получилось совсем не то, что мы хотели”.
Кроме того, отдельного внимания заслуживает сам процесс сбора требований. Обычно, это происходит бессистемно. То есть требования оседают то в памяти менеджера, то в электронной почте, то в логах ICQ. При этом контролировать их поток если не невозможно, то крайне сложно. Добавим к тому требования, озвученные по телефону, и получим следующие проблемы:
- Объем работ растет, причем не контролируемо.
- Сроки изменяются произвольно
- Невозможно провести полноценное проектирование при нечетких требованиях. Это может отразиться на качестве конечного продукта
- В любой момент времени заказчик может отказаться от своих слов. Как итог — потерянное время (в лучшем случае)
- Общий список требований не согласовывается. Соответственно, конечный продукт может не удовлетворять заказчика
Управление рисками.
Ни в одном веб – проекте я не наблюдал полноценного управления рисками. Понятно, что они, в общем-то, одни и те же: неадекватная оценка объема работ и сроков, задержки при согласовании ТЗ или макетов, несвоевременное предоставление оборудования и так далее. Тем более непонятно, почему раз за разом, наступая на одни и те же грабли, эти риски игнорируются. Когда достаточно просто указать соответствующий пункт в договоре (если он конечно же есть).
Да, подобными оговорками можно испугать рядового клиента, который сбежит к конкуренту только потому, что “эти ребята сделают все быстро и без лишних заморочек”.
Это тоже риск. А регулярно сорванные сроки – это не риск испортить репутацию?
Совещания
Проведение совещаний по веб — проекту – довольно большая редкость. Во всяком случае, если они и проводятся, то подготовить и заблаговременно разослать повестку обычно забывают. Естественно, что с таким подходом, про составление протокола вообще речи не идет. Сами же совещания частенько сводятся к парным обсуждениям технических вопросов. В итоге, получается пустая трата времени: что обсуждали – не понятно, какие решения приняты – никто не запомнил, что дальше делать – тоже не ясно.
Работа над ошибками
Мало кто из моих знакомых ПМ` ов смог назвать мне количество проектов, в которых он участвовал. Проблема даже не столько в плохой памяти. Сколько в том, что результаты проекта мало кто анализирует. В процессе написания данной статьи, я даже провел опрос, интереса ради. На момент публикации лидирующим было мнение “Отмечаю в уме, но не документирую” – 25.32%. Причем из того же голосования видно, что только 35% процентов опрошенных проводит полноценный анализ проекта.
Получается, что опыт ведения проектов не накапливается. Так как при отсутствии привычки составлять соответствующие документы, с менеджерами из компании будут уходить и их знания, которыми не всегда можно поделиться при сдаче-приеме дел. Соответственно, процесс развития в управлении может двигаться крайне медленно.
Итого:
Возможно, основная проблема веб – девелопмента в незрелости. В этой сфере очень много молодых специалистов без опыта или специального образования. Многие, получив этот самый начальный опыт, переходят к более серьезным софтверным проектам, освобождая место новичкам.
Иногда возникает вопрос, а целесообразно ли усложнять процесс разработки сайтов, внедряя серьезный менеджмент проектов. Можно встретить убеждение – “Не думай как лучше, просто сделай этот сайт. Будет следующий проект – там сделаешь все по-уму.” Целесообразно, если это позволит выдавать более качественный продукт за меньшее время. Что, соответственно, приведет к снижению расходов. Плюс к тому — бонус в качестве более спокойной, предсказуемой работы – а это, как мне кажется, один из ключей к снижению текучести кадров.
А может быть, дело и в том, что заказчики еще не готовы платить по нескольку десятков (сотен) тысяч долларов за качественную разработку. И правда, зачем, если знакомые студенты сделают ту же работу, только за тысячу — полторы…
Не смотря на это, все чаще можно встретить технические задания на создание сайта, использование User Stories для подготовки к проектированию, итеративный подход при разработке… Мне кажется, это хороший знак, что развитие идет в правильном направлении.
Оригинал здесь
