Менеджменту быть!

🚀🚀🚀Работающий, а не управляющий менеджер проекта - большая опасность 😎😎😎

Во многих компаниях не редкость увидеть, как менеджера проекта пытаются задействовать в роли исполнителя. Мало того, что это моветон, так это и рецепт создания быстрых проблем. Менеджер неизбежно в скором времени встанет пред вопросом: выполнять хорошо и в срок свою часть работы или хорошо и в срок контролировать успехи команды и направлять ее? Конечно, менеджер-исполнитель выберет первый вариант, иначе график работ будет сорван без его погружения в обязанности исполнителя. 😏😒😏

Это так не работает. Нельзя делать менеджеров исполнителями по той простой причине, что если команды исполнителей могли справляться с внутренним менеджментом без внешнего присмотра, то должности менеджера никогда бы не было. Саморегулирующиеся команды - это миф. Если в очень маленьких командах в 3-4 человека это еще может сработать, то по мере увеличения численности проектных групп выполнять одновременно два вида обязанностей невозможно, так как потребности команд и их членов отрывают руководителя-исполнителя от выполнения сугубо рабочей функции. 👩‍💻👩‍💻👩‍💻

Бывает так происходит потому, что в компаниях не понимают, что такое управление проектами. В результате управлением проекта пытаются заниматься все члены команды, что неизбежно приводит к тому, что все те же члены команды не успевают выполнять своих прямых обязанностей. 😶

#management #itmanagement #bestpractices

Почему нельзя допустить потери интерфейса пользователем? 🤔

После такого большого перерыва в заметках не грех поговорить немного и о продакте! ❤️❤️❤️

Мы находимся в мире интерфейсов. Когда вы идете в офлайн-магазин, вы видите множество интерфейсов: ценники, тележка, стеллажи, кассы, кассы-самообслуживания. В большинстве случаев всеми интерфейсами в хороших магазинах занимается сам магазин и не отдает на откуп партнерам или аутсорсерам, но почему?

Представьте, что вы, как владелец магазина, отдали поставку и обслуживание тележек в магазине на аутсорс и теперь в магазине тележки на 3 колесах, доверие к бренду магазина будет падать. Или вы отдали обслуживание и конфигурации касс самообслуживания каким-то подрядчикам и оказалось, что кассы не имеют френдли UI/UX, магазин в данном случае не может влиять на вовлеченность и удержание своего клиента. Данные примеры демонстрируют ситуации, когда пользователь теряет интерфейс. 👨‍💻👩‍💻👨‍💻

Итак, чем опасна потеря интерфейса с пользователем?
✳️ Не влияем на вовлеченность клиента
✳️ Не влияем на удержание клиента
✳️ Теряем информацию о клиенте
✳️ Происходит коммодитизация

Коммодитизация - появление нейтралитета (безразличия) к брендам вследствие того, что разница между продуктами брендов практически отсутствует.

Такие проблемы ведут к снижению маржинальности и капитализации бизнеса. Именно поэтому при разработке своего продукта вам требуется предусмотреть все интерфейсы, с которыми может взаимодействовать пользователь продукта, и держать их на постоянном контроле. К примеру, в онлайн-сервисах не стоит перебрасывать пользователя на страницу платежного шлюза, лучше встроить ее в iframe’ом на странице биллинга сервиса.

Будьте аккуратны в разработке интерфейсов ваших продуктов. 😉

🎯🎯🎯MLP - как MVP, только MLP

Пока проджекты строят процессы и команды, продуктологи придумывают новые слова. 😁

В последнее время тренды говорят о том, что подход MVP становится все менее эффективен. Кажется, это последствие того, что сам подход из рук профессиональных менеджеров перешел в ‘мейнстрим’. Минимально жизнеспособный продукт часто воспринимают не как поставку небольшого, но качественного продукта от огромного запланированного проекта для проверки гипотезы, а как быструю поставку огрызка проекта. Можно даже услышать оправдания в диалогах: “Но это же MVP”. 🤔🤔🤔

Один из популяризаторов подхода The Lean Startup, Райян Сингер, писал про MVP следующее:
“Если вы решили создать функцию, вы должны соответствовать хотя бы базовому стандарту исполнения с точки зрения опыта.” Но на рынке мы часто можем увидеть проекты, которые реализованы хуже, чем аналогичные прошлые. 😞

Я уже сказал, что подход MVP изживает себя, но изживает он себя скорее в понятиях, ведь от этого подхода отказаться очень трудно, хотя при этом что-то пора менять. Теперь в кругу продуктологов вы будете все чаще слышать понятие MLP - Minimal Loveable Product. 🚀🚀🚀

Минимально симпатичный продукт - это MVP, который вызывает эмоции за счет более точного попадания решения в целевую аудиторию. Для примера, вы говорите баристе: “Пожалуйста, приготовьте кофе”. И вы получаете нескафе. В банке. Закрытой. Наглухо. Вам доставили продукт? - да. Довольны ли вы им? - нет. Это частый пример современного MVP. А если бариста спросит у вас, какой кофе вы желаете, и поставит перед вами чашечку американо из свежеобжаренных зерен, то вы будете довольны и получите эмоции от поставленного продукта. Это наглядный пример MLP. ❤️

Какие вопросы мы задаем, когда идем к MLP?

✳️ Какие решения будут действительно решать боль клиентов?
✳️ Какие решения вызовут большее кол-во положительных эмоций?
✳️ Как мы можем вызвать восторг у пользователей при использовании продукта?
✳️ Как мы можем вызвать потребительскую привычку от нашего продукта?
✳️ За счет чего мы сможем сформировать комьюнити вокруг продукта?

MLP - это не нечто новое, скорее, это более конкретизированное MVP в направлении продуктового подхода, появившееся вследствие естественных причин, когда менеджеры устали видеть дискредитацию MVP подхода, который так много привнес в современный мир. Отлично то, что теперь на старте проекта можно всегда спросить: "это будет MVP или MLP?" - и, основываясь на этом, решать, а нужен ли вам еще один ‘огрызок’ в портфолио. 👨‍💻👩‍💻👨‍💻

🤔🤔🤔 Вопрос выбора инструментов - непростой вопрос.

Многие выбирают решения и инструменты для реализации технической части исключительно по функционалу. О, да, посмотрите на этот фреймворк, в котором можно сделать в 3-4 раза больше, чем нужно, когда-нибудь пригодиться.😁 И дело даже не в избыточности, а в том, что через год-два ваша команда захочет съехать с этого фреймворка и вы попадаете в ловушку, мигрировать-то нормально не получается из за того, что за просмотр обилия функционала вы забыли про возможности миграции. 😕

Кейс: вам нужен инструмент для работы с данными, на рынке много приложений с большим функционалом, но на кой черт вам нужно приложение, которое не умеет импортировать или экспортировать в csv или xls? Мало того, что вы будете испытывать боль, так вы не сможете потом безболезненно мигрировать с него на новое приложение. 😱

Я не встречал ни одной команды, которая была бы довольна своим технологичным стеком. В процессе разработки часто намечаются долгосрочные планы на смену инструментов и ваша задача, как менеджера, не превратить переезд проекта на более современные решение в ад. Не смотрите только на функционал, обращайте внимание на возможность миграции. 🎯🎯🎯

#management #itmanagement #it

👀👀👀 Сроки поджимают?

Когда вы понимаете, что релиз точно не выйдет в срок, то мы знаем что делать:

1. Выкинуть часть функционала; 🤷🏻‍♂️
2. Снизить качество работы и начать клепать говно;
3. Отправить команду в овертайм; 👎🏻

Но иногда ваш топ-менеджмент или заказчик все равно остается недовольным. На этот случай отлично работает цитата из книги "Мифический человеко-месяц":

Для программиста, как и для повара, давление со стороны хозяина может определять запланированный срок завершения задачи, но не может определять время ее фактического завершения. Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать еще или съесть его сырым.

У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым — с другого. 👩🏻‍🍳🧑🏻‍🍳👨🏻‍🍳

#management #itmanagement #it

🖥📚🖥 Почему вам стоит уметь работать с инструментами, которые используют ваши сотрудники?

В среднем время на возвращение в задачу, от которой разработчик отвлекся, составляет 20-30 минут. В жаркие деньки вашего коллегу могут “дергать” по разным задачам каждый час и его эффективность значительно снижается, а если вы к нему будете приходить несколько раз в день с простыми задачами, которые можно сделать самому, то разработчик и вовсе будет забывать, чем занимался. 👎🏻❗️👎🏻

Изучите основные инструменты, с которыми работают ваши коллеги ✅✅✅

Если вы работаете с дизайнерами - освойте элементарный уровень Figma или Sketch; если вы работаете с аналитиками - прочтите, как использовать PowerBI; если вы работаете с разработчиками - научитесь ходить в PostMan для проверки запросов и в GitLab для отката релизов. Эти элементарные и действительно несложные навыки позволят вам выполнять правило двух минут, где действие, которое может быть выполнено за 2 минуты, должно быть выполнено безотлагательно, при этом вы упростите жизни всех коллег, с которыми работаете. 🚁💪🏻🚁

Будьте эффективны и помогайте быть эффективными другим. 🚀

👩‍💻🌶👩‍💻 Если вы управляете рисками, то начинайте управлять ими до старта проекта

Мне кажется очень странным, что многие практикуют управление рисками сразу после старта проекта. 🤷🏻‍♂️ То есть бюджет был спланирован и выделен до старта проекта, ресурсы были найдены и выделены при старте, расписание разработали в первые дни и только после составили реестр рисков. Составили и поняли - бюджета не хватит, сотрудников не хватит для полноценной ротации на задачах, а некоторые хай риски, которые случатся с высокой долей вероятности, скорее всего сорвут сроки. 🤦🏻‍♂️

Управление рисками должно быть неотрывно от других стадий планирования, а лучшим решением ставить планирование рисков сразу после бизнес-проработки будущего проекта. Возможно реестр рисков, продвинутый вами до старта проекта, похоронит его до факапа и сэкономит деньги компании. 🧞‍♂️🧞‍♂️🧞‍♂️

#doit #bestpractices #management #itmanagement #it

🚀🚀🚀 Бойтесь своих желаний или как не превратить свой MVP в груду ненужных фич на старте

Многие компании часто стараются запускать минимально жизнеспособный продукт для определения коммерческого потенциала проекта, но в процессе, не обращая внимания на многочисленные ограничения, выпускают продукт с излишним функционалом. Соответственно, если наступает риск отсутствия спроса у продукта, компания теряет огромные деньги сверх изначально заложенного бюджета. 🤷🏻‍♂️

Ребята из uplab написали простым языком отличный, пошаговый гайд о том, как все таки не переборщить с фичами при построении MVP, очень рекомендую к прочтению. 👍🖥👀

🚀🚀🚀 Вникаем в бизнес-процессы компании на старте!

Хочу поделиться своим опытом начала работы в любой новой компании. 🎉Вся наша работа строится вокруг бизнес-процессов, и когда мы приходим на новое рабочее место, многое кажется неясным. Глядя в документацию (если она есть), можно просидеть месяцы, пытаясь понять, в каком направлении движется компания и какие приоритеты ставить перед командой в первое время. Но как раз этого времени у нас зачастую и нет, так как же быстро начать разбираться в бизнес-процессах, за которые ты в скором времени будешь ответственен?

✅ Будем на связи со стейкхолдерами. 🤝🤝🤝

Стейкхолд - это круг заинтересованных лиц проекта, в это понятие включаются не только непосредственные заказчики, но и клиенты, подразделения, которые работают с твоим продуктом из бекоффиса, и многие другие лица, которых касается работа разрабатываемого продукта. Но в первую очередь нас будут интересовать наши бизнес-заказчики.
Вот он, ваш первый день на рабочем месте, вам рассказывают про модули продукта, знакомят с командами и выдают доступы к системам, в голову пытаются уместить огромное кол-во информации и вы к обеду уже начинаете теряться. Предположим, первый день пройден, что же делать во второй?

Почему бы не протестировать какую-нибудь фичу без тестировщика совместно с одним из бизнес-заказчиков? Вы назначаете встречу, открываете модуль продукта и начинаете тыкать в неизвестный вам интерфейс, но рядом представитель бизнеса, который знает, зачем нужна каждая кнопка и, отвечая на ваши вопросы в течении часа, дает вам неплохое понимание о том, зачем требуется модуль, куда внедряется фича, как он работает и какие на него планы у компании. Смотрите-ка, второй день дал много полезного опыта! 👨

Почему бы не тестировать фичи с разных модулей с представителями бизнеса пару раз в неделю? Мне кажется это отличной идеей, и через месяц у вас будет уже неплохое видение проекта в целом.

✅ Составим чеклист!

Все идет неплохо, что будем делать на третий день? Когда вы приходите на должность, у многих людей есть некоторые ожидания к вам, особенно у вашего непосредственного руководителя, так давайте сделаем эти ожидания прозрачными для обеих сторон во избежание недоразумений - составим чеклист. Попросите у своего руководителя список задач, за которыми он хочет, чтобы вы следили первое время - вы получите цель, а руководитель прозрачно делегирует задачи на вас с первых дней.

Прошло 3 дня (которые, конечно, могут затянуться и на неделю), но у вас уже есть некоторое понятие о бизнес-процессах продукта, у вас есть четко обозначенные цели, над которыми предстоит работать, что добавить для идеального вхождения в работу?

✅ Начнем писать личную документацию. 📝

Многие ваши действия должны перейти в разряд автоматических, но на первых порах вы будете много ошибаться: правила оформления задач, порядок администрирования встреч или зоны ответственности коллег из доверенной вам команды - все лучше закрепить для себя в личном пространстве документации, чтобы упорядочить получаемые знания и не тратить время на поиск информации, которая уже была вам известна. 💻💻💻

Следуя этим простым правилам, вы сможете ощутить свои зоны ответственности, быстро вникнуть в поверхностные бизнес-процессы, лишний раз не факапиться, а руководство увидит ваш структурный и системный подход к работе.

Удачного вхождения в новую должность! 🙌

#itmanagement #management #bestpractices #doit

📝📝📝 Как заставить разработчиков писать документацию?

Во всех командах разработки есть текучка, где-то в большей степени, где-то в меньшей степени, но любые изменения в команде - это достаточно большой удар по производительности, ведь для внедрения нового юнита в вашу команду понадобится достаточное время менеджера и коллег по разработке. 👌 Важнейшей ролью в быстром вхождении в проект является документация. Под документацией я не подразумеваю мануалы или техническое описание проекта, это лучше оставить на откуп техническим писателям, мы поговорим о документировании кода, почему зачастую код не покрыт документацией? 🤷🤔🤷

Когда есть проблемы с условиями работы:

✳️ Отсутствие времени на документирование. Если в оценку сроков не вкладывается срок на документирование, соответственно, документировать код никто не будет. Закладывайте время на описание документации.

✳️ Порядок разработки и документирования. В некоторых случаях код принято покрывать документацией на самых ранних стадиях разработки, но при реализации решений кодовая составляющая может меняться несколько раз, что ведет к лишним издержкам, так как старая документация переписывается также несколько раз. Лучше заняться документированием на поздних этапах разработки модуля или по его завершению.

Если все условия соблюдены, может добавить мотивации?

✳️ У разработчиков нет желания передавать опыт из-за застоя в команде. Хорошее решение в данной ситуации: дать разработчику или команде под наставничество 1-2 джунов.

✳️Внедрить KPI, который включает покрытие кода документацией, может пригодиться, если задокументировать хочется как можно больше.
Используйте геймификацию и проводите соревнования, к примеру, у кого из разработчиков больше задач было задокументировано.

Документация - главный инструмент передачи знаний о проекте, она не обязана быть всеобъемлющей, но она должна давать хорошее поверхностное понимание о продукте и ее фичах. Старайтесь мотивировать разработчиков, “объясняться” в коде, тогда и вам, и тому, кто придет на ваше место, в будущем будет намного проще. 🚀🚀🚀

#itmanagement #management #bestpractices #doit

🤔✅🤔 Почему фасилитация так важна в инструментарии менеджера?

Многие из нас работают по скраму, который отчасти создавался на принципах работы в компании Toyota, которые были выработаны в конце 20-го века человеком по имени Тайоти Оно. Этот человек привнес в производственную систему Тойоты одно из главных представлений о ‘препятствии’, на котором базируется понятие ‘непрерывного потока’. Все достаточно просто, чтобы максимально снизить издержки, ключевая задача руководства - выявлять и устранять препятствия на пути течения потока. Полагаю, это достаточно простая концепция, но почему-то мы не думаем о ней ежедневно. 😶

Окэй, что такое фасилитация?. Фасилитация - это процесс управления, направленный на создание пространства для общего понимания команды и принятия ей решений.
То есть мы вкладываем много сил в поддержание качественной коммуникации между сотрудниками и командами, чтобы добиться как можно большего взаимопонимания между коллегами. 🙌

Начинающие менеджеры видят фасилитацию зачастую слишком элементарно. К примеру, один из менеджеров, с которым я работал, сказал, что один из элементов фасилитации - это когда мы на ретроспективе задаем вопрос: “Ребята, какие у вас есть боли? Давайте обсудим и решим их вместе”, - но, увы, это далеко не та фасилитация, которая позволит создать непрерывный поток в работе над проектом и взаимопониманием в команде. ❌❌❌

✅ Вы должны всегда подталкивать людей к совместному решению проблем.

К примеру, на утреннем митинге один из разработчиков сказал, что у него есть проблемы с решением его текущей задачи, и если он не сможет самостоятельно справиться с ней до обеда, то он созвониться с коллегой и попросит помощи. А на митинге следующего дня оказывается, что он также пытается справиться сам и так не созвонился с коллегой для решения проблемы. Это произошло потому, что вы не фасилитировали ситуацию. Вашей задачей было узнать в обед у разработчика его прогресс по задаче, и если помощь все еще требовалась, самостоятельно назначить встречу с коллегами для форсирования событий, такие ситуации в нашей работе и есть препятствия, и если вы не будете фасилитировать проблемные моменты, то вы никогда не получите непрерывного потока. 📈🔄📈

Когда я рассказываю об этом подходе, мне иногда говорят: “Почему я должен за ними бегать? Они взрослые и самостоятельные люди”. Во-первых, эффективность менеджера заключается в эффективности команд, которыми он управляет, и можно говорить все что угодно, но если сроки проваливаются, то это ошибка менеджера, а не разработчика, во-вторых, это прямая составляющая работы менеджера, в-третьих, наши коллеги далеко не всегда автономны в своей работе. 🤔

И самое интересное напоследок. Эффект от качественной фасилитации заключается в том, что со временем команда становится все более и более автономной в принятии решений и исправлении проблем. 🚀🚀🚀

#bestpractices #doit #itmanagement #management

🥃🥃🥃 Again and again about storypoints

Никогда не исчерпает себя тема об альтернативных единицах измерения задач, следственно, и я никогда не перестану повторять, что же это такое. 🤷🏻‍♂️

Предлагаю самое простое объяснение: представьте, что у вас есть яблоко, и вы точно знаете, как быстро вы сможете его съесть - это 1 сторипоинт. После вам дают арбуз и просят оценить его в яблоках. Так происходит оценка всего чего угодно в сторипоинтах.

Если вы сталкивались с объяснением подобной оценки интернам или джунам, вы точно наблюдали большое недоумение. Вы попытались воспользоваться простым объяснение с яблоками, но практического применения ваши коллеги еще не поняли, перейдем к более сложному, ведь яблоко и арбуз примерно одинаковая сущность, а наши задачи никогда не бывают идентичными. 👨‍🏫👩🏻‍🏫👨‍🏫

Давайте посчитаем, во сколько походов в душ вы оцените свой завтрак? Звучит как абсурд, но стоит попробовать.

Чтобы произвести процесс похода в душ, вам потребуется:
✅ Открыть и закрыть двери душевой кабины, намылить губку, поднимать и опускать руки с губкой (оцениваем трудозатраты).
✅ Открывать и закрывать двери мы будем 1 раз, наносить мыло на губку 1 раз, сколько раз мы будем опускать и поднимать руки, предстоит решить (оцениваем объем).
✅ Требуется не поскользнуться, чтобы не потратить лишнее время (оцениваем риск).

Исходя из декомпозиции, мы можем примерно оценить задачу по 3 критериям (трудоемкость, объем и риск) и принять решение, что это 1 сторипоинт. Теперь, оценивая по тем же декомпозированным критериям завтрак, мы можем оценить его походами в душ. 😁😁😁

Концепция сторипоинтов далеко не самая простая для ваших начинающих сотрудников и коллег из-за высокого уровня абстракции, будьте терпеливы, и приводите как объяснение кейсы с совершенно разными сущностями. 🐯👞👘

#bestpractices #doit #itmanagement #managementit #management

🗽🗽🗽Решение споров монеткой или как забить на погрешность и дать команде офигенную фишку.

Чтобы при оценке тасков не возникало споров, принято вырабатывать паттерны решения спорных ситуаций (к примеру, брать всегда большую оценку), как раз эта задача по выработке паттерна встала перед моим коллегой и я хочу вам рассказать о том, что он придумал . В команде моего коллеги всех специалистов по паре, 14 человек, итого 7 пар специалистов, где каждая пара оценивает свой узкий пул задач 👨‍💻📚👨‍💻. Зная, что пары в будущем не станут трио и более, был выработан паттерн - бросок монеты, так как каждого специалиста два, то вероятность 50/50 практически нивелирует погрешность такого способа принятия решения в среднесрочном и долгосрочном периоде, а фишка стала яркой и неотъемлемой традицией команды. 🍻🥃🥂

🧞‍♂️🤸‍♀️🧞‍♂️ Почему калибровку сущностей оценки стоит проводить регулярно?

Недавно мне написал один из тимлидов из “соседней” команды и пожаловался на то, что два его джуна никак не могут адекватно начать оценивать задачи в сторипоинтах, по словам лида, он тщетно перепробовал совершенно все методы объяснения и внушения и позвал меня на планирование для изучения ситуации. ⛑⛑⛑

Эстимирование проводилось по классическому сценарию: planning pocker + шкала из эталонных фич продукта, приравненных к эталонным оценкам сторипоинтов для того, чтобы обращаться к ней при сомнениях в оценке, сравнивать с текущими задачами и калибровать себя. И именно шкала “эталонных оценок” вводила в ступор джунов, как оказалось, эталонные фичи были реализованы более двух лет назад, и этот legacy мало того, что не изменялся более года, но и самые “старшие” участники команды не могли объяснить, как сравнивать новые задачи с тем, что было на этой шкале из-за прошедшего времени. 🤦🏻‍♂️🤷🏻‍♂️🤷🏻‍♂️

Эталонные фичи для одной части команды могут быть не эталонны для другой, очевидно, но мы часто об этом забываем, обратите внимание на то, чтобы у всей команды вес сферических коней в вакууме должен быть примерно одинаковым 😸😸😸

👨‍💻📘👨‍💻Пора собраться и начать писать meeting notes

Все вокруг забывают о договоренностях, к которым пришли 2 недели назад? В спринт не вкинули задачи по техническому долгу, которые хотели взять месяц назад, а дизайнер все еще забывает подготавливать ui киты после 2 ретроспектив? Выход есть - начните вести записи встреч. Этим можете заниматься непосредственно вы, назначенный человек, технический писатель, аналитик или все по очереди - не важно, главное, чтобы все были заинтересованы в закреплении договоренностей “на бумаге”. 🗣📘🤔

Я понимаю, что у вас есть сомнения:
✳️ Meeting notes - это избыточно.

Нет, не нужно бездумно записывать все подряд и тем более вещи, которые за 2 минуты выполняться после встречи. Если у вас проходные задачи, то записывайте только ретро или другие важные встречи, которые непосредственно влияют на постоянный ход работ. Руководствуйтесь здравым смыслом.

✳️ Meeting notes все равно никто не читает, и проблема с неисполнением договоренностей остается.

Вдумайтесь, если ваши коллеги не выполняют договоренности, то они вообще работают? Если да, то посмотрите, куда вы кладете информацию, если это один из сотни файлов в google drive, то никто, конечно, не будет регулярно читать записанные данные. Эти данные должны быть в быстром доступе.

Я веду ретро notes в Slack в таком формате:
1 тред: #ретроспектива от date.date.date
2 тред: 1. Договоренность N1
3 тред: 2. Договоренность N2
4 тред: 3. Договоренность N3

В итоге любую ретроспективу за полгода можно быстро найти через поиск по хештегу или дате, на нее можно сослаться или линкануть человека, который забыл про договоренность в соответствующем треде. 📆🗄🔎

✳️ Meeting Notes никто не хочет вести.

Мало кто любит писать документацию, но вы всегда можете сделать ведение документов “почетным”. Придумайте небольшие, локальные награды за качественную актуализацию notes, популяризируйте ведение записей и сами подавайте пример. 🎊🤝🎉

📝 Записи встреч - это очередной уровень формализации, к которому вы рано или поздно придете, если вы не начнете вести их сейчас, то придете к ним в ситуации, когда долг по договоренностям в коллективе превысит все допустимые рамки, и это станет острой необходимостью, что приведет к насильственному внедрению. Поэтому, чем раньше - тем лучше! 🚀🚀🚀

#bestpractices #doit

🌶👨‍💻🌶 Agile по фиксированной ставке - безумие или реальность?

Целая неделя без постов, а это значит, что кейс этой недели был далеко не тривиальным. Мне всегда казалось, что гибкие методологии и фиксированный бюджет несовместимые вещи, но когда в начале недели передо мной встала задача взять в работу такой проект, я сказал следующее: “weird flex but okey”. 🤷🏻‍♂️🤷🏻‍♂️🤷🏻‍♂️

Проблема состояла в том, что ни юридически, ни технически процессов на такие кейсы в компании, на которую я работаю, в начале недели еще не было, и спустя несколько брейнштормов с руководителями юридического 🧞‍♀️ и PMO отдела 🧞‍♂️ нашлось странное, но жизнеспособное решение.

Bullshit solution состоит в том, что вся работа ведется по T&M сразу на все требуемые фичи с уже спланированным кол-вом часов (T&M договор нужен лишь для того, чтобы оплата происходила не по спланированным, а по фактическим часам), но договор составляется так, что при обоюдном согласии скоуп работ на фичи может меняться. 👀👀👀

Сферически в вакууме: У клиента есть 1 миллион рублей, и на эту сумму он выкупает 3 фичи, оцененные в условные тысячу часов. Звучит как обычный fix price, не так ли? Но все немного хитрее. В договоре указываем пункт о возможности ребалансировки объема времени к целям работ, путем составления дополнительных актов при обоюдном согласии. Что мы получаем таким образом? Возможность гибко подстраиваться под желания заказчика во время реализации первой фичи, путем урезания часов на реализацию других фич или вовсе отказ от них, при этом, заказчик соглашается на это сам, добровольно. ⌚️🤸‍♀️⌚️

Давайте посмотрим на это еще раз:

• К нам приходит клиент с миллионом рублей и просит реализовать 3 фичи для MVP своего продукта.
• Мы начинаем разработку, и на первой фиче заказчик предлагает большой пул изменений.
• Мы составляем дополнительный акт об изменении объема выполняемых работ, где переносим часы 2 и 3 фичи на первую фичу, и продолжаем переносы времени по необходимости в дальнейшем.
• На выходе клиент получает, предположим, не 3 фичи, а 2, но выполненных качественно и, как правило, этого достаточно для MVP.

✅ Жирные плюсы подхода:

👍🏻 Компания предоставляет fix price agile, что встречается исключительно редко, и получает больше контрактов.
👍🏻 Полная юридическая защита при разногласии с клиентом.
👍🏻 Возможность не волноваться за продуктовую составляющую фич, если клиент не готов смещать скоуп, и ему обязательно нужно 3 фичи (fix agile не срабатывает, и проект остается фикс прайс).

❗️ Жирный минус подхода:

👎🏻 В конце работы клиент может посчитать себя обманутым, ведь он получил за миллион рублей не 3, а 2 фичи, следовательно, постоянная разъяснительная работа с клиентом по такой схеме очень важна.

Итогом истории стал разрыв шаблона и предложение новой услуги на рынке. Фиксированный Agile - это фиксированное время, фиксированный бюджет и нефиксированный скоуп.

P.S. Хочу предупредить, что данный подход будет работать только с MVP, где отсутствие реализации каких-либо фич перед выкаткой - стандартная ситуация.

#newpractices #doit