Так как сказать наболело товарищи…
Давеча, поставили мне невыполнимую цель. Есть говнющий такой проект, который нужно доводить до ума, причем всем понятно, что довести его до ума в эти сроки не удается, но особо никаких поправок на ветер не делается.
Единственная цель, по которой все ведется в этом направление, чтобы когда придет срок, то перед заказчиками выглядеть засратыми на по уши, а только по горло. И в этот момент, они считают, что можно выпросить будет отсрочку и опять обосраться, но только по колено, а там гляди еще через пол годика можно вообще из срани выплыть.
Что мне собственно не нравиться, что из-за гиперконцентрации на краткосрочной цели, это самое обсирание самих себя будет длиться долго и счастливо, вместо того, чтобы серьезно решать проблему сейчас, аккуратно толстым слоем размазывается по длительному участку времени.
Так вот, это я о том, что ничто так не демотивирует, как работа над нереалистичной целью, когда понимаешь — буду работать плохо — все будет гавено, буду работать хорошо — все будет гавено, но чуть-чуть меньше.
Я считаю, что единственным разумным методом является установка достижимых целей. Если же подчиненным ставятся недостижимые цели, то это значит, что начальство вместо решения проблем, просто пытается их спихнуть вниз и ждать… а вдруг…
Согласен, бывает и а вдруг, и в таком случае, политика получается достаточно выгодная, но чаще всего это страуссиная политика — видеть проблемы на расстоянии вытянутой руки, но не задумывать о том, чтобы свернуть.
Кто-то об этом писал… А все нашел Death March
Блин, и ведь как выходит. Если все доведено до конца, то менеджмент большие молодцы и получают медальку. Если все заваленно и весь напряг был зазря… ну, что ж.. бывает, не вытянули разработчики.
Увы, в этой ситуации я как раз в лагере разработчиков, что совсем не смешно.
да, но если компания маленькая и переводиться никуда нельзя, можно просто и банально — свалить. Считаю, что время и нервы дороже любого абстрактного профита от сидения на одном месте.
Солидарен и с вами и Станисловом Малкиным (комментарий ниже).
Увы, пока (в течение несколько месяцев) малореалистично.
Так что, спускаю пары.
Послать далеко бродить тех, кто так поступает. Далеко и надолго.
Начал писать многа букв, потом все вытер ибо все прессуется в один совет. Если принимается, то звучит он так: бери инициативу на себя. Сколько сам потянешь, столько и бери. Решай вопросы за менеджера, за клиент-менеджера, за всех, кто по твоему рулит не правильно и доказывай им свою точку зрения. Я стараюсь обычно делать именно так. И обычно все все потом делают по-моему. иногда не сразу, а через 1-2 месяца, когда убедятся, что по ихнему нихера не получается.
М… Это очень шаткая позиция. Называется либо пан, либо пропал.
В хорошем случае, да — победителей не судят. В плохом случае (а на death march обычно встречаются именно они) — заслуживается большая головомойка 🙂
Вот, как раз в тему — только что прочитал. Об управлении проектами в художественной форме.
http://lib.aldebaran.ru/author/demarko_tom/demarko_tom_deadline_roman_ob_upravlenii_proektami/
Через ItBlogs.ru на эту книгу вышел, Михаил Елашкин о ней написали и очень хвалили-с.
Там это называется «проект-зомби». То, что давно мертво, но в чем поддерживается видимость жизни в угоду личным целям кого-то из менеджмента компании. И кстати, там же много чего и о давлении на персонал, и о (не)эффективности сверхурочных работ.
Ну, прыгать ли из самолета, в котором, как в анекдоте, ворона скачет по кнопкам управления — каждый решает сам, но альтернативы понятны. Для меня первый опыт руководства группой был как раз в «безнадежном проекте». Работали мы все в стиле «сделай или умри», я в итоге был от руководства отстранен, зато вроде бы научился говорить «нет».
Как вариант, можно сразу озвучить свою позицию — что считаешь сроки нереальными, готов работать, но не готов нести ответственность за чужой произвол в оценке объемов работы. Озвучить максимально громко, со служебными записками.
Кстати, я фактически так и сделал. Я сказал, что я не считаю, что цель достижима и что имеет смысл работать в таком стиле.
В общем, что приятно, что прямой менеджер в общем-то достаточно толковый товарищ. И хотя он и не смог разрулить эту проблему (и частично даже завязан на том, что она произошла), но все таки он осознает, что цель нереальна.
Так, что мы с ним переформулировали цель. Цель заменили с «закончить проект успешно», на «продвинуть проект как можно ближе к финишу».
Что меня конечно не радует, что новая цель плохо измерима. Но по крайней мере, это сняло часть головной боли.
У Йордона было описано хорошее решение — разбить все функции (требования, use cases, …) разрабатываемого ПО на группы с разными приоритетами. Максимальный приоритет — сделать обязательно, средний — желательно, низкий — как повезет. Если группы примерно одинаковы по объему, то это правило работает неплохо.
Я согласен. Разбиение на приоритеты — очень важная вещь. Только по идеи должен это делать заказчик (так как он лучше всего знает, что ему важно, а что нет).
Если же заказчик хочет ВСЕ — то разбиение приходится делать менеджеру или программисту (что уже явно не лучший вариант), так как не будет отражать на самом деле, что хочет заказчик.
А вот тут уже менеждер продукта (не проекта) словил валенок 🙂
Если он не может твердо сказать заказчику, что c с запрошенным функционалом продукту попа-кеды, то — ф топку товарисча, нам он не товарищ 🙂
А вообще это уже тема кризис-менеджмента, и девелоперу сюда лезть крайне не рекомендуется. Поясню — если менеджмент грамотный, то поправить ситуацию удастся уже с первой-второй итерации (на первой — по пояс, на второй — так, ступни отряхнуть :)). А если управляющий состав ни в зуб ногой, значит нужно брать на себя «бразды правления», или линять оттуда, пока ветер с мелкими камнями 🙂
В противном случае получится такая аллегорическая картина — телега, едущая в пропасть, и лошади, вздыхающие, но не сворачивающие, только все замедляющие и замедляющие шаг 🙂
>А вообще это уже тема кризис-менеджмента, и девелоперу сюда лезть крайне >не рекомендуется. Поясню — если менеджмент грамотный, то поправить >ситуацию удастся уже с первой-второй итерации (на первой — по пояс, на >второй — так, ступни отряхнуть :)).
Да — это самая ключевая мысль, которую стоит действительно выделить.
В критической ситуации, девелоперы фактически уже не могут помочь и надо решать все на менеджерском уровне. Если же все отдается в этот момент на откуп упорности разработчиков, то толку из этого не выходит.
А заказчика можно привлекать постоянно? Если да, то можно применить agile подходы — выдавать ему частые версии. Т.е. поставить перед ним вопрос так: «Будет сделано всё, но что-то раньше, а что-то позже. Выбирайте, что надо раньше».
Правда непонятно, что делать, если заказчик упрется: «Не хочу ничего видеть до срока сдачи проекта»…
Проблема с этими самыми Death March часто состоит в том, что заказчик или представитель заказчика как раз упирается и не хочет признать, что к дате X, есть шанс что фичи Y не будут сделаны.
Опять же, заказчика тоже можно понять, у него могут быть свои завязки на эти сроки.
Понять можно всех. Но, когда все упираются ногами и не идут на уступки и выходит Death March. Все достаточно хорошо осознают, что они не получат, то чего хотели. Тем не менее планы не пересматриваются и не вносится никаких изменений.
Это происходит из-за отсутствия доверия 🙂 заказчик не пересматривает видимо потому, что думает, что если пересмотреть план, то команда и тот пересмотреный план не сделает 🙂 Он бы его с удовольствием еще больше ужесточил, авось вы тогда сделаете что ему нужно 🙂
Нет доверия — нет конструктива.
Да, либо нет доверия, либо есть давящие обстоятельства.
Вот, второй вариант меня удивляет. Это типа людей, которые перебегают перед несущимся поездом, чтобы успеть за покупками.
Я понимаю, есть давящие обстоятельства — надо купить еды, но это же не значит, что надо под поезд бросаться, чтобы сэкономить 5 минут.
Как вариант: особенность заказчика — нагружать нас настолько максимально насколько мы позволяем, и настолько дешево насколько мы позволяем и настолько проблематично, насколько мы готовы бороться с проблемами — и иногда они доходят до достаточно сильного беспорядка или до абсурда, вообще забывая что работают люди а не роботы.
Согласен.
Но, для решения надо быть менеджером работающим с заказчиком. Будучи team lead или программистом, можно выставить планку разумного только для своего менеджера и не более того.
Death March, путь камикадзе и прочие демотиваторы ставящие перед собой единственную цель — Доказать самому себе что ничего сделать нельзя.
Мне частенько приходится сталкиваться с т.н. «невыполнимыми задачами». При этом они как показывает практика вполне выполнимы хотябы потому что не могут быть вокруг одни тупицы и дауны которые все видят но заставляют заниматься невыполнимыми задачами.
При получении задачи которая с первого взгляда относится к «невыполнимым» я делаю следующее:
1. нужно найти всех заказчиков задачи
2. понять мотивацию заказчиков, именно понять, т.е. стать на место каждого и понять почему он хочет именно этого.
3. Забыть поедлагаемые пути реализации. Это тоже нужно потому что каждый заказчик действует исключительно в своих интересах и соответственно предлагает свой путь решения который удовлетворит только его.
4. Выделить три круга задач: должно быть сделано обязательно, желательно сделать, можно сделать. Причем при определении задач учитывать ресурсы которые есть.
5. Написать некоторое подобие стратегического плана, можно его не публиковать, но для себя он здорово помогает утрясти все в голове.
6. опционально но мне помогает взять схему Getting things done (я это в аутлуке делаю) раскидать туда задачи
7. Вперед
Если задача уж совсем смертельная то как минимум ты выйдешь из противостояния достойно 🙂
Удачи.
>Death March, путь камикадзе и прочие демотиваторы ставящие перед собой единственную >цель — Доказать самому себе что ничего сделать нельзя.
Идеи death march и т.п придуманы вовсе не мной. Я бы сказал, эти описания характерных черт проектов — уже стали классикой.
Да, частенько ими прикрываются, просто для того, чтобы отмазаться от ответственности.
Однако, есть два типа сложных задач:
а) Технически сложная задача, для которой не хватает знаний как ее решить.
В таком случае я согласен, обозвать ее death march- полная чушь.
Кстати, я вот об этом писал в статье Решаем не решаемые задачи
http://victorronin.com/2008/02/25/reshaem-nereshaemye-problemy/
Там я говорил, что для сложных технических задач, надо просто пройти на один шаг дальше чем другие.
б) Задача не сложная технически но имеющая большой срок работы и короткие сроки.
Полностью такую задачу решить невозможно, так как чаще всего тривиально не хватает времени, чтобы решить ее целиком.
Теперь по предложенным пунктам:
>1. нужно найти всех заказчиков задачи
>2. понять мотивацию заказчиков, именно понять, т.е. стать на место каждого и понять >почему он хочет именно этого.
В целом согласен. Частенько бывает сложно из-за несколько уровней менеджмента с их трактовками задачи заказчика.
>3. Забыть поедлагаемые пути реализации. Это тоже нужно потому что каждый заказчик >действует исключительно в своих интересах и соответственно предлагает свой путь >решения который удовлетворит только его.
Честно говоря не совсем понял, что в таком случае имеется в виду по путем реализации. Заказчик зачастую заинтересован в результате ему пофиг, как туда доберутся.
>4. Выделить три круга задач: должно быть сделано обязательно, желательно сделать, >можно сделать. Причем при определении задач учитывать ресурсы которые есть.
Тоже согласен. Однако, проблема тут может возникнуть в том, когда зачазчик хочет ВСЕ. Если он не идет на переговоры (в виде расставления приоритетов), то единственный метод — это расставить приоритеты самому, что чаще всего будет на самом деле не отражать реальные приоритеты заказчика.
>5. Написать некоторое подобие стратегического плана, можно его не публиковать, но для >себя он здорово помогает утрясти все в голове.
Вот ту начинаются самые серьезные проблемы. План написан, в требуемые сроки плохо вмещаются даже приоритеты «сделать обязательно», о остальных приоритетах я вообще молчу.
>6. опционально но мне помогает взять схему Getting things done (я это в аутлуке делаю) >раскидать туда задачи
>7. Вперед
Ну и собственно, если невозможно построить плана ведущего к успешному окончания проекта, то 6 и 7 становятся достаточно сомнительным.
Я бы сказал, задача тут должна решать не в разработческом поле и даже не в поле менеджера этих задач, а в работе с заказчиком. Чаще всего нужно заказчику объяснить, что полностью окончена задача в такие сроки не может быть и что разбиение на приоритеты нужно, и что вряд ли кроме приоритета N1 (в который нельзя впихнуть задач больше чем длинной X) сделать что-то вряд ли удастся.
>>3. Забыть поедлагаемые пути реализации…
>Честно говоря не совсем понял, что в таком случае имеется в виду по путем
>реализации. Заказчик зачастую заинтересован в результате ему пофиг, как туда
>доберутся.
Заказчик зачастую не видит некоторых достаточно тривиальных путей решения сложной задачи всилу большого опыта в бизнес домене. Как утрированый пример при сильных головных болях хирурги иногда применяли кровопускание хотя любой обыватель обошелся бы таблеткой аспирина.
>>4. Выделить три круга задач
>Тоже согласен. Однако, проблема тут может возникнуть в том, когда зачазчик хочет
>ВСЕ.
конечно все хотят все, задача сделать максимум и продать его как все и еще немного 🙂
>Я бы сказал, задача тут должна решать не в разработческом поле и даже не в поле
>менеджера этих задач, а в работе с заказчиком.
Угу, в свое время я был на мевсте человека который общался с человеком который общался с заказчиком. Товарищ был очень нервно-истеричный и по любому поводу впадал в панику. Ну так вот этим товарищам надо продавать решения с утроенной силой 🙂 Когда у такого человека нет сомений в правильности предлагаемого решения он скорее всего (в моем случае в 99%) продаст это заказчику. Конечно, такой опыт может быть и негативным.
>Заказчик зачастую не видит некоторых достаточно тривиальных путей решения >сложной задачи всилу большого опыта в бизнес домене. Как утрированый пример при >сильных головных болях хирурги иногда применяли кровопускание хотя любой >обыватель обошелся бы таблеткой аспирина.
М.. Все равно не слишком понимаю. В общем-то в разработке чаще всего нету никаких особо альтернативных путей (особенно когда релиз достаточно близок).
Все что можно предложить — разбиение на приоритеты.
Добавлять ресурсы обычно уже поздно.
И я еще не видел серебрянной пули, которая позволила бы без кардинальных изменений спасать проект.
>конечно все хотят все, задача сделать максимум и продать его как все и еще немного
С одной стороны — естественно, так оно и есть. С другой стороны, люди ж тоже не безголовые и понимают, что в жизни есть ограничения на хотелки. И можно хотеть получить все, но вероятнее всего так оно и не выйдет.
И в этот момент любой нормальный бизнесмен/sales начинает торговаться, вместо упирания рогами.
>Угу, в свое время я был на мевсте человека который общался с человеком который >общался с заказчиком. Товарищ был очень нервно-истеричный и по любому поводу >впадал в панику. Ну так вот этим товарищам надо продавать решения с утроенной >силой 🙂
Да, таки нужно продавать решение о разбиение на приоритеты. Я вообще сказал бы, это редкий случай когда решение работает почти всегда и везде.
с одной стороны Джон полностью прав. С другой действительно есть ситуации в которых давление на заказчика относительно критического пути или реализации конкретной фунциональности проекта невозможно или крайне сложно. поетому согласен со всеми 🙂 все зависит от конкретной ситуации.
в любом случае я лично такие ситуации воспринимаю как вызов. разрулить неразруливаемое интересно, хоть и иногда не возможно. по крайней мере я стараюсь — а ето всегда приносит положительные дивиденты (как минимум опыт).
Мне тоже нравятся ситуации, которые можно/нужно разрулить. Но при этом надо иметь руль в руках.
Когда в руках руля нет, а только чувствуешь во рту вожжи — такие ситуации не доставляют никакого удовольствия.
Я это к тому, что ситуации такие можно все таки рулить будучи менеджером. Программисту тут рулить уже особо нечем.
Скажу больше. Чаще всего не только нечем, но и вредно. Так как с большей вероятностью ситуация будет жопная, то чем больше
ее трогаешь, тем больше оказываешься главным виноватым.
тот кто делает, всегда оказывается более виноватым чем тот, кто сидит и ничего не делает 🙂
Это естественно. Если страх потерять работу на столько силен, то… мог бы и не писать ничего. У нас в стране своих таких хватает и лично я их не понимаю. Я всегда послыл нахер любого начальника, который не слушал моих логичных и адекватных доводов, не имея ничего против. Кстати в СДД меня уже почти 4 года слушают. Вот давеча был спор в предидущей теме. У тебя есть свои аргументы у меня свои. Четких доказательств нет. Я отступаю. Но если у противника нет даже аргументов… то пошел он в жопу 🙂
>тот кто делает, всегда оказывается более виноватым чем тот, кто сидит >и ничего не делает 🙂
Не совсем так. Если ты оказываешься победителем, то ты не оказываешься виноватым.
Соответственно, когда идешь против ветра, то лучше таки побеждать.
Когда победы не предвидется, то идти против ветра, просто для того, чтобы идти против ветра… Для меня (как для целивика) смысла маловато.
а что если бы ошибаешся и твои шансы на самом деле гораздо выше чем ты себе их представляешь? 🙂 Я вот дам 100% что любой человек у которого 200 конкурентов, о которых он ничего не знает, оценивает свои шансы 1 к 200 и думает что лучше ему и не рыпаться 🙂 тем не менее один из этих 200 таки побеждает. очень часто это бывает как раз тот, кто не рассчитывал свои шансы, а просто делал все для того чтобы победить.
Возможно.
А с другой стороны, человек который оценивает себя, выбирает то, где он сможет победить, а вот остальные 199 в этот момент проигрывают.
Так что, на эту ситуацию можно с двух сторон глядеть.
я имел ввиду, что капать непосредственному начальнику на моск — тоже ничего себе занятие. Ответственности никакой, а бонус может быть. А если этот не шарит, то го к тому кто выше. и так далее. пока не дойдешь до самого верха. А если самый верхний ничего не отвечает и считает тебя придурком… то два варианта. либо ты придурок. либо это компания придурков… в любом случае несовместимость 🙂
На самом деле, капать начальнику-начальника на мозг нужно в единственном случае, когда тебе все равно выгонят тебя или твоего прямого начальника из фирмы.
Если есть любые планы по дальнейшему сотрудничеству, то эта стратегия не самая лучшая.
Насчет остального, согласен.
>когда тебе все равно выгонят тебя или твоего прямого начальника из фирмы
Если начальник — лох не адекватный, то такую цель и стоит преследовать. Я не люблю сотрудничать с тем, кто на мой конструктив постоянно кладет с прибором даже не приводя аргументов в ответ 🙂
ok. А что делать, если начальник разумный?
Собственно ситуация такая, что начальник вполне таки не плох. Вопрос в том, что с заказчиком сами себя загнали в патовое положение.
А теперь, с одной стороны проблемы. С другой стороны тот же начальник связан по рукам и ногам.
То есть он ситуацию осознает, но из-за прошлых действий не предпренимает новых.
У нас похожая ситуация была на проекте. Но щас вроде уже нормализовалась. Сейчас мы уже не по уши, а уже примерно по плечи 🙂 Надеюсь к августу будем по пояс 🙂
Ну нам просто все таки удалось убедить заказчика пересмотреть планы и продолжить сотрудничество.
>я имел ввиду, что капать непосредственному начальнику на
>моск — тоже ничего себе занятие.
говно это занятие, честно скажу. Капать на мозк и гундосить о том что все плохо в стиле «мы все умрёёёём!!!» хорошо только в одном случае чтобы на следующей работе рассказывать своим новым сослуживцам как ты дальновидно предсказал всеобщий пиздец. Как показывает практика такие люди сбиваются в группы и табунами ходят по разным конторам которым вскорости приходит пиздец.
Вобщем я о том что нужно быть конструктивным, с другой стороны капать на мозги норамльному менеджеру особо не получится.
Самый правильный выход помоему это понять точку зрения менеджера и попытаться донести до него свою идею по решению ситуации.
>Капать на мозк и гундосить о том что все плохо в стиле “мы все умрёёёём!!!”
Это не правильная трактовка моей фразы.
>понять точку зрения менеджера и попытаться донести до него свою идею по решению ситуации
Это правильная трактовка моей мысли.
>понять точку зрения менеджера и попытаться донести до >него свою идею по решению ситуации
На самом деле, вопрос состоит в том, что делать, если до менеджера не доходит идея.
Возможно идея неправильная, возможно обстоятельства, возможно менеджер.
Странно было бы предположить, что идея правильная, менеджер нормальный и понял идею, обстоятельства не мешают идею выполнить, но менеджер этого не делает.
>говно это занятие, честно скажу. Капать на мозк и гундосить о >том что все плохо в стиле “мы все умрёёёём!!!” хорошо только в >одном случае чтобы на следующей работе рассказывать своим >новым сослуживцам как ты дальновидно предсказал всеобщий >пиздец.
C другой стороны, говорить все заебись, у нас все отлично, когда на самом деле все фигово, тоже опасная стратегия.
Само собой, постоянно капать в стиле «мы все умрем» толку мало. Но вот капать на мозг в конструктивном стиле, вполне таки полезно.
>я лично такие ситуации воспринимаю как вызов. разрулить
>неразруливаемое интересно, хоть и иногда не возможно. по крайней мере
>я стараюсь — а ето всегда приносит положительные дивиденты (как
>минимум опыт).
О! ППКС! 🙂
полезное http://safari.ibmpressbooks.com/0130094862/ch07lev1sec3
Нужно обязательно сообщить, что сроки нереальные. Написать служебку, сказать об этом на совещании. Везде и всюду все обсуждения начинать с указания на нереальность сроков и сообщать Вашу оценку сроков с разными оценками вероятности.
Если заказчик сроки продлить не может, то поставить его перед фактом, что пострадает функциональность и качество. Открыто спросить какой функциональностью н пожертвует. Поставить перед фактом, что в случае если он не примет решение, то вы выбрали функциональность 123. Попробывать донести эту информацию до заказчика. Или хотя бы до Вашего начальника, вместе проще будет.
Согласен решение, как по мне — самое правильное.
Именно так и предлагает поступать Йордон в Death March =) да и бьольшинство советов в комментариях так или иначе его цитируют 🙂 мудрый дядько
ооо как знакомо 🙂 только я рефлексировал чуть по-другому: http://cotoha.info/thoughts/the-main-pm-mistake/
P.S.: а это был бы _первый_ комент тут, если бы сначале на «MySQL has gone away», а потом не акисмет 🙂
проверка вредности акисмета :]
Прочел, отличная статья.
Кстати, мне вообще большинство статей понравились, которые у вас читал.
Единственное, что скажу, что для решения проблем с проектом, нужно чтобы все стороны были заинтересованы — заказчик, менеджер, разработчики. Если одна из сторон фелонит, то по большему счету усилия остальных сторон уйдут на то, чтобы теребить ту самую фелонящую.
естественно 🙂