Comments 19
Забавный пример хабротелепатии. Как раз думал о подобных инструментах.
На самом деле, наверное, НЕТ - это не телепатия. Просто в сентябре люди выходят из отпусков и вынуждены разгребать массу дел. Поэтому статья актуальна.
Описание простых вещей длинными запутанными текстами, да ещё и множеством способов, есть путь к долгой печали. Печаль будет, когда вас поймают на имитации бурной деятельности и симуляции результативности этой деятельности.
Потопить проект можно двумя способами: чрезмерно углубляясь в каждую мелочь, или же не придавая значения важным деталям. Чаще всего, конечно, с успехом комбинируют оба эти метода.
Эх, как же мы жили и расставляли приоритеты до изобретения таких замечательных методик?! Хорошо, что настоящие эффективные менеджеры в айти наконец-то взялись за дело и напридумывали столько всего полезного, простого и понятного, чтобы решать такие невероятно сложные задачи как "расстановка приоритетов".
Можно ещё методику как стикеры на доску клеить?
Есть и такая.
NIZHNY NoVGOROD - Ne Ispolzuy Zelenie Holodnie Nelipkie Ymajki, No o Velikih Golubih Ochen Razumno, O Doska
Возможно руководствуясь интуицией ;)
Многое зависит от сложности проекта и зрелости команды. Бывает сложно выбрать и договориться, что делать в первую очередь.
Множество раз наблюдал в проде и сайты без товаров, и приложения без базовых функций, но с классным дизайном, который очень хотелось заказчику.
Поделитесь своим методом, возможно он лучше.
Нет, руководствуясь интуицией это делали только те, кто не совсем понимал что, зачем и как делает.
Если вы знаете ответы на эти вопросы, и на вопрос "что будет, если вы это не сделаете?" то вашему эффективному менеджеру не составит труда проанализировать эти ответы, сопоставить их с текущим контекстом вашей работы и понять ценность того или иного действия. Собственно, это и есть приоритет. И от сложности проекта или команды это не зависит.
Я не знаю как у вас, по моему опыту, все, кто хоть немного умели руководить и нести ответственность за свое руководство делали это за секунды. Все остальные пользовались методиками с придуманными цифрами и аббревиатурами.
Спасибо за Ваш мнение. Мне тоже не известно как у вас ведутся проекты. Но скажу с уверенностью, что если в проекте 1 заказчик и 2-3 стекхолдера, особые методики не обязательны, но каких то принципов всё же придерживаетесь.
Но когда продукт включен в корпоративную архитектуру. В составе стейкхолдеров несколько руководителей смежных отделов.
В беклоге за годы уже накопились десятки запросов, и при старте нового сезона, добавили ещё задачи, выбрать и договориться, что ставить в приоритет не так просто.
Руководство, это тоже наука. Нужно знать как обосновывать свои решения и для команды и для заказчиков.
Даже интересно, каким образом количество стейкхолдеров, чем они руководят, сколько задач в бэклоге и какая у вас архитектура влияет на то, как вы принимаете решение?!
Потому что, обычно, это должно влиять на то какие вы принимаете решения.
Простой кейс (укрупнено).
Продажи заказывают новое избранное с оцифровкой данных для повышения продаж. Маркетинг выводит новый продукт, заказывают обновленный фронт + требуются новые интеграции. ИБ заказывает логирование и повышение защиты данных из за нового законодательства, иначе будут штрафы. Исследование показало, что клиентам мешает долгая загрузка каталога.
Каждый считает, что его задача самая срочная и важная. К следующему релизу команда успевает выпустить только 2 задачи. Какое примите решение?
Укрупненно, выберу то, что принесет компании больше денег.
Чуть менее укрупненно, получу ответы на обозначенные выше вопросы и сам решу, что для компании будет полезнее. Или пойду к тому, кто уполномочен для принятия таких решений.
Вы случайно не из команды телеком оператора или компании на последнюю букву алфавита? (без обид, шучу)
Задача продукта приносить деньги снижая риски компании, создавая приток и возврат пользователей, за счет этого будет развитие проекта и рост бизнес метрик.
И давайте по-честному, на этапе планирования, вы не знаете какая из задач принесет больше денег ;)
Я бывал в командах телеком операторов и вы больше похожи на их представителей, говорящих о том, что командам сложно о чем-то договориться из-за большого количества желающих что-то сделать.
По честному, все, что мы делаем сводится к зарабатыванию денег компанией. Естественно, вы можете только с определенной долей вероятности предположить, что и когда надо делать, чтобы принести компании больше денег, дорабатывать функционал, предотвращать риски информационной безопасности или развивать бренд продукта. И, вот, когда вы проанализировали факты и учли риски, вы, как менеджер, которому доверен столь дорогой ресурс как "команда", принимаете решение и выставляете команде приоритеты. За что потом и несете ответственность.
В народе это называется субординация.
Спасибо за интересный диалог и ваше мнение. Действительно, продукт должен приносить деньги бизнесу. Достигают этой цели продукты по-разному.
Предлагаю сойтись на единой сути, нужно проанализировали задачи, учесть риски и принять решение. И для принятия решения нужен придерживаться определённых принципов. Моя команда выбрала MoSCoW
Нононо, ласты с подсветкой — красиво и помогает старой акуле найти себе завтрак!
А почему не MuSCoW?
указанная методика, имхо, не учитывает технический аспект.
архитектурные задачи, требующиеся для стабильной работы системы, обеспечения требуемых характеристик системы , безопасность, обеспечение инфраструктуры работы ("где джавадоки, вашу мать?! почему нет юниттестов? почему не прогнали интеграционные тесты? как так нету их ?!!!! что значит у нас апи не позволяет получить токен без участия человека??"(с)) -... короче вот такое и не только - должно идти в первом приоритете.
как бы пользователь не хотел что то очень важного, без обеспечения технических задач, погоня только за пользовательскими фичами - это как правило медленное погружение в технический ад, значительное замедление разработки, накопление снежного кома технического долга.
т.е. у нас должны быть не 4 колонки, а матрица 16 ячеек))) пересечение mscw по пользовательскому приоритету, и по техническому - с точки зрения влияния на архитектуру и технической критичности.
т.е. вспоминайте RUP - есть пользовательский приоритет, есть технический. архитектор+аналитик вместе приоретизируют задачи на итерацию потому что их взгляды противоположенны - один отстаивает потребности системы, второй - желания пользователей.
не важно как считать, rice, ice, mocsow - да хоть экспертами оцениваете по шкале критично, важно не важно - это только способы получить веса приоритета.
важно помнить, что в разработке ПО есть 2 этих взгляда. 2 разных приоритета. а вы балансирует между ними в ходе работ итерации.
Пользовательские фичи указаны для простоты сравнения, это же метод приоритизации, а не оценки объема и сложности задач. )
И этот подход как раз дает команде возможность обосновать почему нужно выделить время в спринте на тех. задачи.
Если архитектора не устойчива или пора обновлять библиотеки без которых дальнейший рост продукта не возможен, задача ставится в Must. И если заказчик "топочет ножками" что нужно еще пару пользовательских фич ту даже добавить см. п.9 Используйте этот момент для переговоров: запросите дополнительные ресурсы, упрощение требований или пересмотр сроков.
У всех свой опыт и разный характер у заказчиков. В развитых командах заказчик слышит и принимает обоснованные доводы. Но именно обоснованные, а не «вы не понимаете, потому что так правильно».
И вообще, давайте на примерах.
Метод MoSCoW — универсальный инструмент для приоритизации задач любого масштаба