Comments 14
В принципе все мои действия были именно из такой логики.
А вот на счет не принимать на себя — тут сложнее. Если бы я хотел просто работы, я бы так и программировал дальше. Но я сам сделал выбор и теперь часть моей работы — ответственность в том числе за чужие ошибки, которые я не смог исправить.
Но я понимаю, что эти проблемы не самые проблемные ситуации в нашей жизни. Хотя многим казалось, что я так переживаю за проект, что они пытались меня успокаивать. В эти моменты было тяжело сдерживать улыбку от осознания насколько люди меня не понимают)
Хорошо сказано
Нет митингам! Ход конем) Только одна планерка совместная по понедельникам для накидки новых ближайших задач или совместного решения по тем, что застряли. Концепт простой, если мы не будем контактировать самостоятельно друг с другом — у нас вообще нет шансов. Так зачем соблазнять людей митингами, до которого можно отложить обсуждение проблемы. Есть проблема — звоним сразу, заодно начинаем общаться друг с другом. А это уже и есть — проблески команды
п1. Думаю я не смог донести суть. ТЗ как раз было, и в договоре зафиксировано, и изменения только дополнениями. И делалось ТЗ за отдельную денюшку. А х2 я делал уже на проект реализации этого ТЗ.
п2. Очень нужен был, и даже архитектор с тестировщиком были выделены.
Про митинги знаю, как раз хотел показать, что иногда кто-то делает "неправильно". Тоже моей сугубое ИМХО.
п3. Не знаю, может так и подумали. Чужая душа загадка) Мне как и всем эти проблемы были озвучены на общем собрании, я их "переваривал" с командой проекта. Своим быть цели не ставил, это мне было фиолетово, а вот честность да, хотелось. Сразу скажу — это не сработало, те кто ушел, просто поставили перед фактом.
п4. См комменты к п.1 Все оплачивалось.
п5. Не понял. Суть была про то, что иногда деньги есть, а стульев нет)
Кстати про оценки и сроки: жизненый пример тестового кейса пару недель назад от руководителя — есть богатый заказчик, который хочет крутой сайт, контакта с ним нет, архитекторов и разрабов не отвлекать по пустякам, через неделю скажи сроки и бюджет! Не нашелся что цензурное ответить))
п.6. Да, такое ТЗ и было. Бэклог наполняли по фичам, которые нужны были Заказчику. Аналитики? Нет таких)
Документ процесса сдачи делали уже в ходе проекта.
п.7. Да, знаю такое мнение. А что мешает быть уверенным "внутри" команды?
п.8. У меня немного другая ситуация. Изначально все все проговорили, записали. Только видать плохо друг друга слушали. В итоге это я давил на заказчика, чтобы изменить ТЗ.
Спасибо за хорошо описанный опыт.
- Формально — в тот момент когда вы согласились на сроки х1.5, надо было и бюджет делать х3.
Но вопрос, возникающий из оговорки "заказчик в шоке" — насколько это с ним обсуждалось? В том числе — возможность сразу уточнить ТЗ. - Команда распределенная и нет митингам.
Несмотря на отсутствие митингов, вы сами как рп как часто общались с каждым членом команды?
Очень надеюсь, что не раз в неделю.
И отсюда сразу вопрос — вы только рулили проектом, или использовали свой тех.бэкграунд и пилили функционал?
Распределенная команда при прочих равных — доп риск. - Вопрос не к вам. Проект может быть с постоплатой, но вы или обсудили это на берегу (если фриленс команда), либо работодатель платит в срок.
- Фишка — крутая. А оценку влияния этих новых требований на проект в целом проводили? Оценить требование- не значит оценить объем переделок основного тела проекта. И это частая ошибка.
- Не совсем оценка управления рисками. Там не только бабло закладывается. Вся важность работы с рисками в том, что планы по работе на риск готовы до его возникновения. Явные и внятные. Если это ресурсный риск — у вас уже есть рамочный договор с подрядчиком или письмо от фриленсера, что до такого-то числа он готов включится в проект на таких условиях. Если просто деньги в баночке — это не про риски.
- Не понял, совсем. Не указано, чем список требований был западней.
- Врать нельзя. В тот момент, когда вы стали врать — у начальства перестала болеть голова. Даже если вы не видели этой боли — она была подсознательно. А еще с этого места начальство скажет — ты же писал, что все ок, теперь сам.
- Не совсем верная оценка ПМа, но достаточно похожая на правду.
Если от изменений не отвертеться — надо очень четко обговорить на берегу.
Смена приёмника вообще не должна влиять, если все прописано четко.
Но тот факт, что производительность "всплывала" — говорит о том, что четкости не было. А раз не было явно прописано, то шло на понятия.
А дальше диалог:
З — слушай, ну форма за полчаса это ад
ПМ — согласен
З — и что, ничего не сделать?
ПМ — в целом, есть варианты, но надо…
З — класс, жду с доработками, так не приму.
P.S. такое редко бывает в целях проекта. Но это всегда есть в целях ПМа. Иначе результат тоже будет без цели.
От себя: круто и честно, искренне. Не скажу, что проект любой бы сделал, но что часть проблем идет от признания самостоятельного, про маленький опыт — и это логично. Идеальных с рождения руководителей (и не только проектов) не бывает.
Тут много проблем и от компании вижу по описанию.
И есть проблемы от вас же.
Но если это первый опыт — то это не плохо в целом)
- С Заказчиком не обсуждалось, так как я сам еще был не в теме по тех части.
- Чистый РП. Тех знаний и времени сесть в разработку не было. Когда люди входили в проект общался чаще, чем дальше, тем меньше.
- Предоплата, платили в срок, с деньгами траблов не было.
- Чтобы этого не было, работы по которым шли изменения в проекте сразу отодвинули в конец еще на старте.
- У меня есть пулл ресурсов от компании, так что доп деньги позволяют мне взять оттуда человека. Снижение вероятности риска. Хотя согласен это хилое управление рисками.
- Тем что требования были некорректными и не приводили к реализации фичей. Они тупо были не протестированы. И возникла делема — делать то что нужно или то что в ТЗ?)
- Ага, мне даже один человек пытался рассказать что я не вижу, но у них сильно болит голова. Но в реальности мне сказали — ты сам! А после этого я стал врать, а не наоборот. Так же можно?)
- В целом было быстрое и устраивающее Заказчика решение, но метрик из ТЗ не проходили. Вот тут должны были сработать soft скилы. Но увы, "немощен да слаб"))
P.S.
Хотелось честно, потому что это редко пишут в статьях, а ведь это информация для выводов из опыта. Самый обычный реальный кейс. Таких бы в кучку собрать и была бы книжка не хуже PMBoK)) IMHO
Просто он включает в себя не весь опыт, а то, что сообществом выбрано как хорошие кейсы.
Про 6 пункт — когда делается изменение, оно оценивается от и до. От того, как повлияет (не только прямо), до того — как его принять и подтвердить. Это реально целая отрасль, оч слабо развитая у нас из-за факторов, которые всем известны. Надеюсь, что всем) У меня эти факторы были и не из-за заказчика и плохой проработки.
И по п.7 — можно все, что не запрещено. Мне кодекс этики однозначно запрещает. У вас такого ограничения сейчас нет. Но в плане нужно ли и у кого как болит голова — почитайте ради интереса В.Моженкова, «Ген директора». Там есть интересный пример, почему не стоит. В итоге приводит к негативу.
PMBoK это методики, которые дают практики, но они не дают никакого опыта, потому что нет примеров и цепочек логических. А жизнь она чуть чуть сложная и правила хорошо, но вот чтобы не ждать этих уточнений новых редакций, нужен опыт, который вполне можно получить из анализа предыдущих кейсов. Наверное поэтому есть 100500 книжек))
Это было понятно, что это приведет к негативу. Это был принятый риск.
Это не учебник) Это напоминалка тем, кто это знает. Чтобы это учить — другие книжки. А готовиться — третьи.
Это как кодекс у юриста. Он вроде это все знает, учил и сдавал — но книжка на столе лежит и ты посматриваешь. А заходит клиент, берет и прочитав статью пожимает плечами. А ты еще и комментарии смотришь, хотя знаешь. И практику.
Но это не по теме уже)
Вот как раз про практику и была моя статья, чтобы показать — "Идеальных не бывает"(с)
И была пища для подумать увидев чужую "войну".
"Три пути ведут к знанию: путь размышления — это путь самый благородный, путь подражания — это путь самый лёгкий и путь опыта — это путь самый горький."(с)
Может кому-то это снизит количество горьких таблеток.
Ошибки по срокам, объему, оплате, наобещать клиенту и уйти в туман, это по нашему. Автоматом головняк для всех на проекте. Если попросили х2, то можно было и х4, либо сделать нормальную оценку, надо понимать, что проблема не ваша.
Люди это проблема только если в первом пункте это не было учтено. Митинги особенно ни на что не влияют, если их количество разумно, а для команды это полезно.
Оплата опять же напрямую вытекает из первого пункта. И вряд ли это проблема менеджера.
Новые требования само собой нельзя включать без увеличения сроков и стоимости, это надо донести до заказчика, при желании можно тут оценку завысить.
Риски в таком проекте максимальные, потому что сроки выбраны на пределе. Разумеется крайние на этом празднике жизни - обычные разработчики.
ТЗ это спасение и хоть какая-то гарантия, что с вас не спросят лишнего, это надо донести до заказчика сразу. Если ТЗ размыто - это снова проблема из первого пункта и лучше бы обсудить с заказчиком.
Если уже взялись за такой тонущий проект, то говорить начальству, что все хорошо нельзя, потому что иначе вся ответственность ложится на вас и вашу команду. Они должны быть в курсе всех проблем и понимать, что вы и команда делаете все возможное, работаете на пределе. Вам ведь даже спасибо не скажут потом, потому что вы работали в обычном режиме, якобы.
Договорится с заказчиком можно, если он вменяем, хоть и трудно. Надо быть готовым, что есть хотелки, от которых не удастся отказаться ни при каких обстоятельствах. Разработчики как правило знают на чем можно сэкономить.
В итоге это худший проект для разработчика, потому что его будут постоянно торопить: "Как дела? Когда ? Что будем делать?", он будет овертаймить даже стрессовать, ошибочно считая, что не успевает (там где успеть нельзя по определению). Для менеджера это руководство по тому как делать не надо. Вобще, мне кажется от таких проектов имеет смысл отказываться либо ставить вопрос об ответственности ребром.
Тонкая красная линия моего проекта