Продукты и проекты, что выберете вы?
Хочу задать вопрос – как вы думаете, насколько связаны успешность ПРОЕКТА и успешность ПРОДУКТА?
Оглянитесь по сторонам – нас окружают телевизоры и телефоны, планшеты и машины, квартиры и дома, в которых мы живем. И нам, как конечным пользователям, часто безразлично, насколько успешны были проекты, которые привели к их созданию – в установленные сроки (on Time), в рамках заявленного бюджета (on Cost), с намеченным объемом работ (on Scope).
Успешность ПРОЕКТА напрямую не связана с успешностью ПРОДУКТА.
Можно привести массу примеров успешных проектов (on Time, on Cost, on Scope), которые на выходе имели провальные продукты. И наоборот, проблемные проекты (например, перерасход бюджета или серьезный сдвиг по срокам) рождали успешные продукты, которые затем взрывали рынок и приносили своим создателям большую прибыль, а конечным пользователям ценность.
Определение проекта согласно PMBOK: Временные усилия, направленные на создание уникального продукта или сервиса.
Простите за эгоистичность, но все, что меня интересует как пользователя – классные продукты. А еще я уверен, что в этом эгоизме я далеко не одинок в этом мире. Если продукт успешный – люди им пользуются и покупают, если же нет – уходят и находят более качественный и/или удобный аналог.
К сожалению, большинство компаний до сих пор живут в старой проектной парадигме. Заключается fix-price контракт или одна из его разновидностей, а дальше главной задачей менеджера проекта остается максимальное следование первоначальному плану, чтобы втиснуться в узкие рамки «золотого треугольника» – Time, Cost, Scope.
Скрам и продукты.
Хочу обратить внимание на то, что Скрам не является «методологией управления проектами» – определение, которое часто можно встретить.
Скрам – это фреймворк для разработки и поддержки функционально сложных ПРОДУКТОВ (Скрам Гайд, июль 2013).
И еще одна цитата:
Скрам – это фреймворк, в рамках которого возможно решать сложные адаптивные проблемы и, в то же время, продуктивно и креативно разрабатывать ПРОДУКТЫ наивысшего качества (Скрам Гайд, июль 2013).
Фокус Скрама направлен на разработку высококлассных качественных продуктов, которые должны радовать конечных пользователей (нас с вами), и приносить удовлетворительный ROI их создателям.
Слово «проект» встречается в Скрам Гайде всего один раз:
Каждый Спринт может считаться ПРОЕКТОМ длительностью не более одного месяца. (Скрам Гайд, июль 2013).
Таким образом, если вы проработали недельными Спринтами в течении двух месяцев, то вам удалось поучаствовать в восьми проектах.
Желаем смерти всем проектам.
Исходя из всего выше изложенного, я приглашаю вас присоединиться к нашему призыву (полностью читаем в статье «Желаю смерти большинству IT-проектов»):
Я хочу, чтобы большинство IT-проектов ушло из жизни. Более того, хочу, чтобы они вообще никогда не родились. Хочу, чтобы само понятие проектов, применительно к разработке программного обеспечения, вымерло и осталось в далеком-далеком прошлом, как покинувшие эту землю динозавры много миллионов лет назад. А наши дети лишь улыбались при упоминания слова IT-проект и рассуждали, а существовали-ли они (проекты) на самом деле, или это все бабушкины сказки.
Меня привлекли человечный подход, ставка на живое общение и постоянное стремление увеличивать ценность. До этого работал менеджером проекта, и разница на лицо.Денис Сальников из N26 В Скрам-мастера стоит идти, если вы хотите помочь сотрудникам профессионально развиваться и вместе улучшить процесс работы, — у вас будет достаточно влияния, чтобы бросить вызов устаревшей системе управления. Ещё эта роль подойдёт тем, кто хочет выпустить передовой Продукт, — Скрам-мастера больше всего нужны инновационным компаниям.
Я пришла в новый отдел маркетинга, что помочь производителю программного обеспечения освоить рынок b2c. В компании уже был заметен Аджайл, но не было маркетинга как такового, и никто не знал, как маркетологам использовать Скрам. Я стала кем-то вроде проводника знаний о фреймворке.Лана Сан из AGILE CAFÉ 敏捷教育訓練中心 Если вам нравятся правила Скрама или вы хотите попробовать его в своей отрасли, тогда вперёд. Осталось разобраться, каково вам будет в новой роли и как её освоить.
Нужны терпение и навыки фасилитации. Скрам-мастер не может дать ответ напрямую — только подвести к нему.Лана Сан из AGILE CAFÉ 敏捷教育訓練中心 Скрам-мастером стать проще, если вы уже были неформальным лидером в коллективах. Сможете разрешить конфликт любой сложности: с отдельными сотрудниками, между Командой или в компании. Проще будет и оптимистам, которые не боятся изменений. Действия Скрам-мастера дают результат не сразу, и вашего запала должно хватить, чтобы довести всё до конца.
Большая часть работы Скрам-мастера — развитие коммуникаций, и ему пригодится умение договариваться со всеми в формате win-win.Михаил Скляренко из «Моего дела» Скрам-мастером стать сложнее, если вы не айтишник и не эйчар. Тренер Unusual Concepts Сергей Лобин советует найти опытного коллегу в качестве ментора. Ещё сложнее придётся людям, которые любят контролировать каждый шаг Команды.
Людям с сильным эго и глубокими техническими познаниями труднее всего воздерживаться и не влиять на принятие всех решений.Денис Сальников из N26 Если вы обладаете подходящими качествами или ваши качества хотя бы не усложнят работу, осталось воспользоваться одним — готовностью учиться.
Практика нужна, чтобы строить Скрам в компании, фасилитация — чтобы хорошо проводить встречи, а коучинг — чтобы лучше работать с людьми.Андрей Редин из «Альфа-Банка» Обучаться правилам Скрама — обязательное условие. Иначе вы не сможете оценить, насколько строго их соблюдают, и не сделаете компанию гибкой. В процессе обучения важно усвоить ценности Аджайла, чтобы знать, когда от правил Скрама можно отступить в пользу Продукта. Обучаться можно у аккредитованных тренеров. Это необязательно, но существенно увеличит шансы сдать экзамен и получить международный диплом.
Нельзя рассчитывать, что знание наизусть Руководства по Скраму без усвоения ценностей Аджайла поможет стать хорошим Скрам-мастером.Михаил Скляренко из «Моего дела» Обучаться коучингу можно в Международном Эриксоновском Университете или на тренингах. Есть тренинги по конфликтологии, бюджетированию — все они расширят ваш кругозор. Обучаться фасилитации стоит у крутого фасилитатора. Сергей Лобин советует Дмитрия Лазарева.
Умению слушать людей научиться тяжело. Но фасилитация ещё на старте поможет завоевать доверие сотрудников и компании.Сергей Лобин из Unusual Concepts Если вы уже обучены, поищите стажировку. В каждой компании свой Скрам, и чем больше увидите, тем лучше поймёте суть. Говорят, в «Альфа-Банке» уже пробуют стажёров. Можете устроиться и в штат. Полноценную роль Скрам-мастера предлагают в крупных компаниях. Спасибо Денису Сальникову, Лане Сан, Михаилу Скляренко, Андрею Редину и Сергею Лобину за помощь со статьёй.
Максим, спасибо за ваш комментарий. С большим опозданием, но, все таки, отвечаю
Статистика 20 последних лет IT проектов показывает, что в золотой треугольник попадает 14-26% (посмотрите развернутую статистику Standish Group по годам) проектов. Похоже на игру в русскую рулетку, не правда ли? :) В запутанных средах (Cynefin) треугольник постоянно расползается и нет возможности фиксировать все 3 переменные (Time, Cost, Scope). К слову, радует, что в этом году Standish Group изменила критерий успешности проектов в своих отчетах и включила в него Business Value. Вспомните, когда вы последний раз делали ремонт у себя в квартире, насколько вам удалось войти в Time, Scope, Cost? :) Как говорит мой дядя, который 20 лет находится в строительном бизнесе "Я видел, чтобы ремонты заканчивались позже, но никогда не видел, чтобы они заканчивались раньше".
это именно то, от чего мы хотим отойти в Аджайл и то, что нашло отражение в 4-й ценности Аджайл Манифеста "Responding to change over following a plan". Я не хочу, чтобы команды тщательно продумывали то, что они будут делать через год, потому что турбулентность IT среды сводит подобные усилия к нулю. Аджайл фреймворки используют планирование в стиле набегающей волны. И всегда помним, что план теряет актуальность в момент его завершения. :)
в PMBOK качество является одной из переменных и может быть снижено, что на практике и происходит, когда в погоне за сроками на команду разработки оказывается давление и, как результат этого, снижение качества. И наоборот, если мы возьмем Скрам, то качество - константа (DoD) и не может быть снижено от Спринта к Спринту. А сам Скрам является инструментом, который максимально минимизирует риски. Каждый Спринт - это отдельный проект (фиксированное время, стоимость и плавающий scope), на выходе которого имеем готовый к инспектированию продукт.
Максим, боюсь, что это желание невыполнимо, потому что моя работа заключается в практиках создания успешных продуктов, а не проектов. Проекты меня не интересуют как таковые.
Мне бы, все таки, очень хотелось бы, чтобы они (проекты) просто исчезли :) А работать по настоящему Скраму очень просто - необходимо выполнять лишь то, что написано на 17 страницах Скрам Гайдах. Это просто :)
Илья, с интересом прочел вашу статью. Не буду скрывать, полезной информации в ней не получил, но, вместе с тем, убедился в том, что мейн-стрим (не нашел хорошего аналога в русском языке) аджаил/скрам направлений в их современной трактовке в большой степени состоит из мифов, оговорок, поверхностных знаний.
Я уже подробно однажды рассматривал одну из ваших статей (http://vishmaks.blogspot.com/2014/02/blog-post.html) и не смог пройти мимо этой, так как количество предметных ошибок в ней весьма велико.
Дальнейшее не сочтите за критику лично вас - это только мои мысли по поводу информации в статье.
Не могу согласиться, что успешность проекта не связана с успехом продукта. Ваше видение успешного проекта ограничено временем, бюджетом и скоупом. Но эти показатели всего лишь операционные ограничения проекта. А у проекта есть цель, достижение которой и является успехом проекта. Или неуспехом, если цель, а не ограничения, не была достигнута.
Перерасход бюджета или сдвиг сроков сами по себе ни о чем не говорят без понимания причин. Эти события могут быть только следствием предпринятых (или непредпринятых) проектной командой и заказчиком действий. Если в ходе работы над проектом заказчик видит, что необходимо больше средств/времени из-за первоначальной недооценки объема работ, то почему проект необходимо считать неуспешным.
" ... а дальше главной задачей менеджера проекта остается максимальное следование первоначальному плану, чтобы втиснуться в узкие рамки «золотого треугольника» — Time, Cost, Scope" - с этим тоже сложно согласиться. Главной задачей менеджера снова таки является достижение проектных целей. По этой фразе я только могу сделать вывод, что вам не повезло с проектами и менеджерами в них.
Мне совершенно непонятно, почему в вашем представлении заключение контрактов с фиксированной ценой является устаревшей парадигмой. Ограничения заставляют тщательнее продумывать планы, уделять внимание рискам и качеству. Странно, что аджаил-тренера не любят такого рода проекты.
Немного о проекте/продукте. Очень правильно замечено, что скрам является удобным и эффективным фрейворком по разработке продуктов. Это верно в части понимания продукта как результата работы команды по разработке программного обеспечения.
Но если я заказываю проект по внедрению, например, системы электронного документооборота в организации, то продуктом будет не просто софт, а работающий программно-аппаратный комплекс с обученным персоналом. А для этого необходимо управлять закупками, подрядами, обеспечить техническую и технологическую инфраструктуру. Просто софт меня, как заказчика, не устроит, так как цель такого проекта не разработка софта, а решение бизнес-задачи. И такого рода продукты не готовятся с помощью только одного скрама.
Не мне давать вам советы, но очень бы хотелось, что тренера/коучи давали объективную информацию, базируясь на широком опыте и практиках управления проектами. Иначе и далее большинство проектов будут работать по скрам-но(у).