Комментарии 35
Наивысшим приоритетом является удовлетворенность заказчика, кроме случаев, запрещенных законами, условиями контракта и позицией топ-менеджмента.
Пункт вроде бы правильный, но содержит в себе основной проектный конфликт. Удовлетворенность заказчика, условия контракта и позиция топ-менеджмента (с обеих сторон) в подавляющем большинстве случаев расходятся. Именно в этом и есть суть управления проектом — найти компромисс между этими крайностями. Или, иными словами, команда в лице своего лидера, должна иметь собственную железобетонную позицию, которую сможет отстоять и перед Заказчиком и перед собственным руководством.
Пусть это будет цинично, джаст бизнес, в случае заказной разработки, если релиза не случилась, а заказчик удовлетворен, готов подписать акт и перевести деньги — это отличный результат проекта.
Переформулирую классическое определение термина проект на следующий: «Проект это ограничение по времени предприятие, целью которого является удовлетворение интересов заказчика». Если в результате проекта случилось не только полное удовлетворение заказчика, но и родился новый уникальный продукт, то так тому и быть (поход в квартал красных фонарей и получение там удовлетворения это таки тоже проект… просто без уникального результата)
Тогда давайте так и формулировать приоритет — подписанный акт и полученные деньги, причём в срок и с запланированной маржинальностью.
Это может произойти и при не вполне удволетворенном заказчике, в силу договора. Либо наоборот — для удовлетворения заказчика часто приходится выходить за границы проекта (сроков и бюджета, соответственно).
Кроме того, в более-менее серьезных проектах есть функциональный заказчик, есть бизнес-заказчик, есть владелец бюджета, есть тот, кто следит за формальным исполнением контрактов (заказчик может плакать от счастья но вы всё равно получите пени за просрочку даже в один день). И чем крупнее заказчик тем сложнее всё это будет устроено.
«Проект это ограничение по времени предприятие, целью которого является удовлетворение интересов заказчика»
С таким подходом, это верный способ вылететь в трубу для проектного бизнеса. Да и внутренние проекты с таким определением делать не рекомендуется.
Я говорил о том, что в некоторых случаях заказчик может быть удовлетворен, если результат проекта достигнут только на бумаге. То есть не было существенных трудозатрат ни с одной стороны. И все стороны довольны. Для бизнеса исполнителя — это манна небесная.
такое бывает, братцы, и не так редко, как вы сейчас подумали.
И сразу прикладывайте пруфы, пожалуйста. Я вот не знаю таких примеров, что бы долгий релизный цикл шел продукту на пользу. Зато много примеров, где короткий релизный цикл помогает. Ну, например, фиск багов :)
То есть, наш цикл не должен быть ни длинным, ни коротким — он должен быть подходящим для наших потребителей (у которых есть свой цикл, длительность которого не всегда совпадает с нашим).
Про фиск багов ;) — не вопрос. Но даже в этом случае выпуск новой функциональности вполне может проходить по совсем другому, более длинному циклу.
Продукту может быть и нет, но проекту — вполне. Часто лучше потратить пару месяцев на ТЗ, согласовать его, чтобы потом иметь железобетонные рамки, ограничивающие бесконечную фантазию заказчика.
… и именно из-за такой расстановки приоритетов мы имеем (особенно на рынке мобильного софта) туеву хучу откровенно мусорных, глючных и потребляющих как не в себя аппаратные ресурсы приложений.
Наивысшим приоритетом должна быть удовлетворенность потребителя, которая далеко не всегда закладывается в требования заказчиком, и в этом случае, по-хорошему, разработчику следовало бы хотя бы попытаться объяснить заказчику важность этого приоритета. Да, естественно, обязать разработчика следовать такой этике нельзя. Но можно распространять и пропагандировать её среди разработчиков.
«Розовые щеночки» (локальный мем среди дизайнеров — когда заказчик пытается удовлетворить, в первую очередь, своё ощущение «правильности» продукта в ущерб привлекательности продукта для потребителя) станут появляться на рынке реже тогда, когда заказчики поймут, что всё меньше исполнителей соглашаются изготовлять подобный отстой.
И лжепророки эджайл будут каяться…
Требуется: добежать до цели всей командой, за минимально-возможное время
Традиционный подход: Оцениваем способности каждого члена команды, выявляем какую среднюю скорость он способен поддерживать в течении длительного времени, при необходимости заменяем слишком медленных на кого-то пошустрее. Берем скорость самого медленного, скидываем еще немного на всякие непредвиденные обстоятельства и даем старт.
В результате команда с очень большой вероятностью прибежит к цели в расчетное время, возможно даже слегка раньше.
Аджайл: У нас есть марафонская дистанция, и есть толпа сильных профессионалов! Отлично!
Что есть марафонская дистанция? Это ничто иное, как триста спринтерских дистанций! Отлично! Измеряем скорость каждого члена команды на стометровке — она намного выше чем скорость рекордсменов-марафонцев. Видите какой отличный у нас подход! Все получится, ведь мы самая лучшая, сильная команда замотивированных профессионалов!!!
Стартуем! Заодно, что-бы не было скучно, давайте в конце каждой стометровки будем менять конечную цель, отодвигать ее немного, ну заодно и маршрут поменяем.
Что случилось!? Почему команда крепких, замотивированных профессионалов лежит на земле, тяжело дышит и на требования подняться и бежать, шлет всех матерно? Мы ведь не пробежали еще и километра! Плохая команда, плохие профессионалы! Нам нужны другие люди, а не эти ленивые жопы!
Шутка, конечно, но в каждой шутке…
Измеряем скорость каждого члена команды на стометровке — она намного выше чем скорость рекордсменов-марафонцев.
Вроде обычно скорость команды измеряется целиком. Я правда только про скрам и канбан знаю.
Правда вот так что-бы от и до все соблюдали — такое я на своей практике только один раз видел. По началу было забавно, потом «высокое руководство» сказало что хватит тут х… й страдать, вы уже три месяца тут ритуальные танцы вокруг костра исполняете, а проект стоит на месте (а он реально стоял на месте, потому что мы из-за всей этой супергибкости раз по двадцать переделывали пяток начальных страничек) В итоге от аджайла остались одни митинги по утрам, да и те проходили обычно «на отлюбись».
Agile это скорее про добавление pacemaker в вашу команду, который будет выдерживать плановый темп на разных участках. В беге не так заметно, но например в speedskating роликовый пак едет сильно быстрее отдельного спортсмена…
Меня как-то после армейских маршбросков на 10 км., в полной выкладке, на марафонские дистанции не тянет бегать, как-то не слишком приятные воспоминания, хотя и понимаю что марафон бегут налегке. Поэтому даже и не интересовался раньше, сколько там конкретно километров.
Стартуем! Заодно, что-бы не было скучно, давайте в конце каждой стометровки будем менять конечную цель, отодвигать ее немного, ну заодно и маршрут поменяем.
В конце каждой трехсотметровки помимо прочего еще и ленточку рвать нужно, интервью раздавать, самому опрашивать зрителей о том все ли им понравилось, и в зависимости от их ответов менять стратегию, технику и темп бега на следующем участке.
Если команда изначально состоит из профи, то в некоторых случаях эта методология может приносить пользу. Что совершенно не обозначает обязательности её применения всегда и на всех проектах. Решать нужно по ситуации, как работать.
Мы к сожалению не в идеальном мире живём, и требование к уровню профессионализма может быть попросту невыполнимым. Нужно уметь делать проекты с теми людьми, что у вас есть.
И вот исходя из этой предпосылки, разве не следует, что область применения Agile должна быть серьёзно пересмотрена? Командам из сильных профессионалов оставить право использовать её или нет, в сборных командах из разноуровневых специалистов перестать её навязывать. А в некоторых случаях давать по рукам манагерам, которые по разным причинам просто рвутся внедрить ритуалы, без понимания основ.
Ещё один манифест