Главная ошибка проджект менеджера или думайте хорошо
Хорошо и много думайте, прежде чем согласиться на проект. Отказывайтесь, если вам не оставляют свободы манёвра. Или хотя бы отдавайте себе отчёт в своих возможностях, дабы избежать разочарования.
К чему это я? А вот прислали картинку (ещё 13го сентября) и навеяла она мысли… а сегодня (о блин, уже вчера!) пришёл проект от сейлов с офигенно понятным скоупом, и я про неё вспомнил. Когда этот пост задумывался, причина была более веской лично для меня, сейчас уже нет – я проекты пока не веду. Но написать, чувствую, всё равно стоит – может _того_ менеджера успокою 🙂 ну типа присказка закончилась, началась сказка…
Наверное самая распространённая ошибка руководящего состава – искренне верить, что из говна можно вылепить конфету. Ошибка не в том, что конфету нельзя вылепить… ошибка в том, что нельзя надеяться при этом, что конфета будет вкусная.
Итак вот возьмём ситуацию, когда у вас есть проект с:
- неопытными разработчиками (коты);
- плохими требованиями (топор);
- невозможностью его не делать и что-либо менять (дверь закроется и проект превращается в закрытую систему).
Знакомо?
Непременно удивляет уверенность высшего руководства, что в таких условиях менеджер может “не делать глупостей”. А что ему ещё остаётся, такому одинокому в этой закрытой комнате?!?
Более того, плохие требования даже с хорошими разработчиками заканчиваются “кровью” – разработчики, которых всё задрало, бодро уходят в неизвестном направлении…
Что делать-то?
Спешу обрадовать – универсальный рецепт есть. Ура! Тот самый случай, когда there is a silver bullet. Всё просто – надо пахать:
- Каждое требование заново выяснять с заказчиком – для простоты можно считать, что требований нет, т.к. плохие требования часто запутывают, вместо помощи;
- Подключать тестирование заранее – пусть требования тестят на предмет полноты, непротиворечивости и верифицируемости (к сожалению, помогает только, если специалисты по QA опытные);
- Махровым цветом должен цвести микроменеджмент – как всегда при неопытных разработчиках;
- Защищать своих разработчиков – они ни в чём не виноваты:
- Иметь в виду, что начальные сроки уже просрочены, просто в силу того, что они были назначены из требований, которых нет. Начальные сроки разработчикам даже озвучивать не надо – озвучивать только то, в чём сами уверены, например срок сдачи первой итерации согласно новым требованиям (заново оценённый и перепланированный);
- Иметь в виду, что в начальный бюджет вы не попали, просто в силу того, что в нём не было графы “выяснение требований”. Это даже если оценка самих требований не изменятся, а они изменятся;
- Не брать проектов в дополнение к этому. Из опыта известно, что плохой проект “высасывает” время из всей остальной деятельности. Что характерно – при нанесении непоправимого ущерба остальной деятельности, плохому проекту это помогает очень редко. Хз в чём тут дело.
- И не париться, если ничего из этого не помогло. Вернее, конечно надо провести разбор полётов, понять, что таки делалось не так, но без депрессий. Этот пункт применять только, если вы заранее знали, что проект – плохой. Если этот пункт применять к любому заваленному проекту, то ой. плохо. пора уходить в дворники.
Как видим, в принципе, ничего страшного нет. Точно так же, как и нет времени ни на что больше 🙂 Но, тем не менее, “плохой” проект реально вытянуть, надо только взяться за него серьёзно с самого его начала.
А вот тут собственно мы и возвращаемся к началу поста – чтобы разглядеть “плохой” проект, надо внимательно смотреть на все и хорошенько думать… Потому что, если в середине или конце проекта, говорить, что он, мол, плохой – это уже отмазки, и нифига не конструктив.
P.S.: чуть не забыл. Дальнейшее чтение: Эдвард Йордон “Путь камикадзе” (Death March)
Хотелось бы узнать мнение о такой постановке раскладов – требования есть, заказчик уверен что они идеальны (а как иначе? 2 ночи доку писал), по ним уже что-то можно лепить, но в итоге много мелких вопросов всплывает. Больше брать ответственности на себя или больше тормошить заказчика по мелочам?
Типично такая ситуация наблюдается когда заказчик – далекая от ИТ компания, а вы – их подрядчик.
Более подробно об описанных “серебрянных пулях” стоит почитать в “Путь камикадзе” Эдварда Йордана.
IMHO MustRead книга.
На практике полностью им следовать не удается, но плоды свои они все-таки приносят.
зависит 🙂
Если ты знаешь предметную область, то можно смело брать ответственность.
Если нет, то лучше тормошить и честно признаться, что, мол, мы не знаем, что делать, поэтому будем следовать требованиям буквально. и привести 1-2 примера, которые показывают, что следовать буквально чревато. Клиент репу почешет и начнёт отвечать на вопросы по делу – КРОМЕ СЛУЧАЕВ, когда он посредник. Посреднику чхать на результат – его задача перекачать деньги от клиента тебе с удержанием процента… бойтесь таких.
ну… в общем случае не согласный. ИТ это настолько общее понятие, что не ясно, кто от неё далёк, а кто близок.
например, дизайн-студия – близко или далеко от ИТ? а сделать им сайт – это ого-го скока гемора 🙂
с другой стороны, завод Интеркондиционер – вроде совсем далеко, а сайт как с пол-пинка. потому что обычный каталог и минимум придирок.
в общем на самом деле всё зависит от задачи, а не от сферы деятельности заказчика. Вот у меня есть животрепещущий (как стрела, которая попадает в цель трясётся, вот так и этот пример, гад, трепещет живо и болезненно).
Есть сайт по продаже заказов в отели. Казалось бы, да? Та часть, которая продаёт вылетела как угорелая, т.к. все мы в теме, как выбирать и покупать товар.
А вот часть, которая формирует товар (выборки по датам, комнатам, окнам на море, скидкам, детям, акциям, дополнительным кроватям, пепельницам, койкоместам, дополнительным услугам, бесплатным дням, процентам, комиссиям, ценам, исключениям, рандомым числам, настроению заказчика и прочим хренотеням) до сих пор болит (Фатал, привет!)
тока кстати эти каменты больще подходят к http://cotoha.info/thoughts/being-on-the-same-line-2/ и http://cotoha.info/thoughts/being-on-the-same-line/ 🙂
Вот как раз случаи “когда клиент – посредник” – они и наиболее часты в нашей практике. И закрывают тебя в комнате с топором и пытаешься говорят тебе: “ну ты же умный – разберись с ним сам – ведь все есть!” При это, как правило, речь идет о доработке “живой” системы, которая а) по каким-то причинам перестала работать; б) по каким-то причинам перестала удовлетворять конечного потребителя; в) владелец бизнеса “хочет сделать чтобы было современно”. А чаще и то, и другое, и третье сразу – причем 3-й пункт наиболее злобный из всех, поскольку а) не поддается формальному описанию (“ну ты же умный – придумай сам!”) – а стало быть и верификации на выполнение; б) чаще всего возводится в максимальный приоритет: ну вот любит “хозяин” “эти всякие новые штучки – сделайте чтобы и у нас такое было!” И возможность пообщаться с конечным потребителем продукта или хотя бы приобщиться к этому общению: заставить саппорт вести записи о каждом обращении – ага! как же! ведь у нас есть “аналитики”! А “аналитики” “анализ писать” где учились? Правильно! В наших вузах: чем больше воды “про то как наши корабли бороздят просторы большого театра” – тем лучше! Вот так и живет… 🙂
2 The Lex
фигасе тебя зацепило… “выдыхай бобёр” (с) а если по сути, то
1. зарегистируйся, тогда сможешь править свои каменты, а то за ошибками смысл теряется… чего ты там пытаешься?
2. по-секрету, у нас нет специальности, которая бы готовила аналитиков, поэтому “аналитики анализ писать” вообще нигде не учились. что с одной стороны страшно (в большинстве случаев, т.е. ~95%), а с другой хорошо (в случаях светлой головы, не порченой ВУЗовскими догматами).
Вернее, конечно надо провести разбор полётов
—-
Я бы добавил, что разбор нужен не один. А много и регулярно “разбирать” и “заново собирать” эти самые полеты 🙂 И не забывать при этом изменять бюджет (и/или рамки)…
А поможет в этом… угадай что? 🙂
Процесс управления рисками 🙂 Прочитал я про щетину, и вижу, что с теорией все “Ок”. А вот тот списочек, который ты привел в пример (из 4 пунктов) – скорее ухудшает настроение, чем улучшает (хотя и похож на шутку).
Риски – наше все! Остальные инструменты – просто инструменты. Изучил, попрактиковался, и используешь на автомате. Социальный и коллективный аспекты командной работы – отдельная тема, которая и без менеджмента живее всех живых. А вот риски…
2 Артур
прошлая неделя по моим ощущениям была самой отстойной за последние полгода, так что я счас сам не скажу – это злая шутка или я правда так думаю…