Пожалуйста, опишите ошибку

Нашли баг? Помогите нам его исправить, заполнив эту форму

5 ошибок управления проектами

Владимир Опацкий
Руководитель проектов

Здравствуй, дорогой читатель! Наверняка ты часто встречал статьи под названием «Как руководить проектами». Я хочу рассказать о том, как нельзя руководить проектами. Об основных допускаемых ошибках пойдет речь в моей статье. Кстати, они не случайно так пронумерованы. Чтобы быть максимально корректным и никого не обидеть (а еще не получить по шапке), проект и разработчики останутся инкогнито.

5-errors_large

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

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

К слову, даже за две недели до конца изначального дедлайна я не переживал насчет контента, ведь в тот момент нам было нечего с ним делать.

За две недели до конца срока у нас не было готово ровным счетом ничего. Ничего не работало или работало криво, а разработчик пожимал плечами, говорил, что контента нет, что он молодец и в сроки мы уложимся в любом случае. Я верил!.. Я верил ему целый месяц до этого. Но каким-то образом товарищ умудрялся “продать” нам то, что он справляется. Стиснув зубы, я продолжал ему верить…

Всегда говорят, что один из основных инструментов руководителя − делегирование. Ситуация, о которой я рассказал, отлично описывает фатальную ошибку номер 4 нашего проекта – делегирование контроля.

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

После этого начался калейдоскоп тяжелых событий: совещания на повышенных тонах, переработки, посиделки по ночам… Но в конце концов проект был запущен. Позже, чем планировалось. Не в том виде, в каком планировалось. С кучей нервов и неприятных впечатлений.

Меня спасло то, что коллеги мои − люди золотые. Благодаря им мы справились с проблемами и вышли из нелегкой ситуации.

Теперь у тебя может появиться резонный вопрос: «А когда произошла фатальная ошибка под номером 1? С чего все началось?». Дорогой читатель, ты дошел до самого интересного.

Она начала назревать еще до моего назначения на этот проект. Ребята думали, какой же выбрать инструмент для разработки. Никто из них не представлял, что в итоге будет делать система. Были какие-то наброски спецификации, и все подумали, что WordPress − отличный выбор, а шаблон поможет сохранить время.

Ошибка состоит в том, что в момент изучения материалов по проекту я молча согласился с этим выбором. Даже не обратил внимания!

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

Недавно я прочитал книгу Максима Батырева  «45 татуировок менеджера. Правила российского руководителя». Автор повествует о своем пути руководителя на примере своих и чужих ошибок. Каждая глава освещает одну тему, которую Максим называет татуировкой.

По итогам этой статьи я могу сформулировать свои 5 татуировок для руководителей проектов по разработке программного обеспечения:

  • Всегда обращайте пристальное внимание на выбор технологии. Зачастую это определяет возможность внесения изменений и поддержки будущего продукта.
  • Всегда описывайте требования к продукту и тем более к обязанностям заказчика как можно более подробно и жестко.
  • Всегда реагируйте на невыполнение обязанностей клиентом или третьими лицами, которые участвуют в проекте. Кто-то что-то не предоставил в срок? Сроки сдачи продукта сдвигаются!
  • Всегда сами контролируйте ход разработки. Забудьте о делегировании контроля. Вы должны видеть прогресс своими глазами. Если прогресса нет, это сигнал к незамедлительным действиям.
  • Всегда стойте на своем. Никто (а особенно клиент) не может знать лучше, сколько же еще надо времени до конца проекта. Игнорируйте все угрозы, если знаете, что срок нереален. В итоге перенос сроков заранее будет гораздо менее болезненным, чем отсутствие продукта в день релиза.

Это был очень ценный опыт, хоть и обошелся мне и компании достаточно дорого. Надеюсь, тебе моя статья поможет. Удачи!

Читать и комментировать
Как мы настраивали CI

Георгий Кирий

5 августа 2015

Как мы настраивали CI

Skobbler maps

Марк Левковский

4 августа 2016

Skobbler maps

Работа с JSON в MySQL

Максим Лимонов

9 января

Работа с JSON в MySQL

Xposed magic will be here

Сергей Опивалов

28 ноября 2016

Xposed magic will be here