Телеграм канал «Дмитрий Сорокин | Дневник_Манагера»

​#знания #кейсы #горькаяправда #моимысли

ЧАСТЬ 5. Финал.

За месяц до релиза мы отдали билд тестировщикам клиента и получили обратно список критических дефектов. Эту часть в кейсы не выносят. 🙅🏻‍♂️

7 апреля. Первый билд в UAT для внутренней группы тестирования клиента. То, что вернулось – было не косметикой.

Неделю мы чинили, потом отдали исправленный билд в тот же UAT. К 14 апреля основной функционал MVP был готов на 90-95%. 15 апреля стартовало внешнее тестирование.
В конце апреля билд ушёл на проверку в сторы. В начале мая приложение вышло.

Хочу быть точным, потому что фраза "мы уложились в срок" многое скрывает. В декабре я оценил проект ближе к маю. Но, к сожалению, согласовали более сжатые сроки. Затем клиент сдвинул дедлайн с 31 марта на 30 апреля. А в марте даты скорректировали ещё раз: подача в сторы в конце апреля, публичный релиз в начале мая. То есть сроки вернулись к моей изначальной оценке.

На UAT мы договорились чинить только дефекты, но параллельно приходили новые запросы. Вероятнее всего, без них релиз случился бы раньше, но клиент поступил иначе.

Что я ставлю себе в плюс: скоуп устоял. Мы ничего не выкинули втихую в надежде, что никто не заметит. И команда не выгорела на финише.

Что не ставлю: у меня не получилось отстоять свою оценку в декабре. Но, по факту, сроки всё равно к ней вернулись, только в марте и через нервы.

Что бы я изменил. Мы отдали билд тестировщикам клиента слишком поздно. Неделя критических дефектов в апреле – это неделя, которую можно было прожить в марте, если бы я продавил UAT на 70% готовности, а не ждал версии, за которую не стыдно. Ждать, пока продукт будет выглядеть законченным – это инстинкт ПМ. И обычно он подводит.

Приложение уже в сторах. Оно для людей, которые живут с хроническими и редкими заболеваниями, и для тех, кто хочет общаться и находить близких по духу с похожим диагнозом. Именно это держало команду, когда срок не держал.


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

❓ На вашем последнем релизе срок выдержали или, все-таки, перенесли? На сколько и почему?

​#знания #кейсы #горькаяправда #моимысли

ЧАСТЬ 4

Самое ценное, что я сделал на этом проекте – удалил фичу. 😱

Кастомные реакции. Фича лежала в скоупе MVP с первого дня и выглядела маленькой. С 26 декабря по 7 января логика под ней оставалась нерешённой. Каждое обсуждение открывало новую ветку. Кто может реагировать, на что, что происходит с реакцией при редактировании поста, и как всё это должно работать внутри закрытого сообщества людей с редкими диагнозами.
Двенадцать дней встреч – ноль строк кода. 🤦🏻‍♂️

🦾 Я настоял, и 8 января клиент согласился убрать её из MVP. Не потому, что фича плохая. Настоящая цена фичи почти никогда не в разработке. Она в том, сколько времени на решения она забирает у всех, неделя за неделей, пока кто-нибудь наконец её не прикончит.

🙅🏻‍♂️ Моя ошибка здесь следующая: этот вопрос надо было выносить на третий день. А я позволил обсуждению дизайна тянуться почти две недели, потому что оно выглядело продуктивным, разумным и взвешенным. Но по факту, оно было не продуктивным, а дорогим.

Что дало удаление: уже через неделю, 15 января, авторизация и онбординг были готовы, и моя команда показала демо клиенту. Через 24 дня после того, как был готов SOW, клиент увидел работающее приложение у себя на телефоне. Это демо изменило тон всего сотрудничества сильнее, чем любой мой статус-отчёт.

С тех пор у меня правило: если элемент скоупа обсудили трижды и не приняли решения, то он перестаёт быть элементом скоупа и становится вопросом на решение. Я несу его человеку, который может сказать “да” или “нет”, с двумя вариантами, рекомендацией и датой, к которой мне нужен ответ.

🤔 Где это не работает: если клиент привязан к фиче эмоционально – удаление обойдётся дороже в доверии, чем сэкономит во времени. Тогда ход – не удаление, а перенос на следующий этап. Тот же разговор, но другое слово.


📝 В последней, пятой части: неделя, когда билд ушёл на тестирование и вернулся весь в критических дефектах.

❓ Какую фичу вы убили последней, и заметил ли это хоть один пользователь?

​#знания #кейсы #горькаяправда #моимысли

ЧАСТЬ 3

Шесть недель моя команда была полностью укомплектована, полностью оплачена и полностью заблокирована. Ни один burndown этого не показывает. 🫠

Цифры той зимы. К 5 января у нас всё ещё не было доступа к App Store Connect и Google Play Console. 8 января к нам присоединились два разработчика для усиления, и весь цикл запроса доступов пришлось начать заново уже для них. Доступ к Google Cloud дали только 13 января.

Ничего из этого не решалось тем, чтобы работать усерднее. Это как раз то, что тяжело объяснить человеку не из delivery.
Вот моя настоящая ошибка. Месяц я добивался доступов по официальному каналу. Тикеты, напоминания, вежливая эскалация. Двигалось медленно, потому что на той стороне это был чей-то четвёртый приоритет, а тикет этого не меняет.
9 января мы провели первый совместный инженерный созвон. Наши разработчики и их, без менеджеров-переводчиков посередине. Вопросы с доступами начали закрываться за дни, а не за недели.

Этот созвон надо было организовать на первой неделе. На нём оказался человек, который смог быстро выдать всем доступы и разблокировать работу. Да и на звонке запросы, как правило, работают лучше, чем в переписке, где сообщение теряется среди остальных.

Но заказчик был новый, люди новые, кто есть кто – ещё неизвестно. Поэтому я осторожничал и соблюдал регламент коммуникации. Зря. Эта осторожность стоила нам почти всего декабря.

Что я делаю иначе теперь: в первые две недели ищу человека, у которого реально лежат доступы, а не того, кто ведёт с нами отношения. Это почти никогда не один и тот же человек.

И я стал напористее. Даже наглее. Не успокаиваюсь, пока вопрос не решён. А роль человека на той стороне для меня почти перестала иметь значение: сильные аргументы работают на любом уровне.

Где это не работает: иногда за задержкой стоит реальная политика безопасности, и никакой созвон её не сдвинет. Но понимаешь это быстро. Как только инженер на той стороне говорит "это решает комплаенс", давить на людей бессмысленно – они сами ничего не решают. Тогда меняешь вопрос: не "когда дадите доступ?", а "к какой дате комплаенс даст ответ?". Дату фиксируешь в рисках, и заказчик видит, во что обходится каждая неделя ожидания.


📝 В следующей части: фича, которую мы удалили, и двенадцать дней, которые она нам стоила до этого.
❓ Сколько вы максимально ждали доступ, который должен был занять час? 🤔

​#знания #кейсы #горькаяправда #моимысли

ЧАСТЬ 2

Первый месяц на этом проекте я им не управлял. Управлять было ещё нечем.

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

Так что месяц ушёл на “заливку фундамента и прокладку труб”.

После того, как нам удалось с большего сформулировать SOW, дальше пошли: воркфлоу с гит-флоу, записанный и презентованный команде и заказчику, чтобы никому не приходилось гадать, что происходит после создания тикета и после его проверки QA, AC, DoR и DoD, планы коммуникации, рисков, etc. Звучит очевидно. Но это не очевидно. На большинстве проектов, куда я приходил, воркфлоу жил в голове у PMа, а остальные догадывались.

Ответственность и кто что решает. Я назначил тимлида, вместо размытой схемы, где команда равна и формально отвечают все. Когда отвечают все, не отвечает никто.

Воркфлоу в JIRA, собранный под то, как эта команда двигает работу, а не шаблон, который кто-то однажды включил и больше не открывал.

Git flow. Я PM, а не инженер. Хотя мой путь начался именно с разработки. Но мнение свое у меня всё равно было, и большая часть его прижилась, тк я понимал, как это настроить.

Карта стейкхолдеров на стороне заказчика, чтобы вопросы доходили до человека, который может ответить, а не в общий ящик.

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

Несколько недель этого не было видно. Потом стало видно сразу везде. Когда в декабре срок сжали, никому не пришлось выяснять, кто что решает, и на этот вопрос мы не потеряли ни дня, потому что я сразу четко обозначил и расставил все точки над i.

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

📝 В следующей части: шесть недель, когда команда была полностью укомплектована, полностью оплачена и полностью заблокирована.

❓Сколько у тебя уходит первого месяца на новом проекте на процессы, прежде чем что-то поедет?

​#знания #кейсы #горькаяправда #моимысли

ЧАСТЬ 1

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

Начну с приложения - мобильной социальной платформы Drops с AI/ML для людей с хроническими и редкими заболеваниями. Всего будет пять частей постов из этой серии. Аппка уже в сторах, так что это уже не NDA. 😎

22 декабря. Три недели мы вытягивали из заказчика требования и превращали их в SOW с нормальным скоупом на MVP. Оценку мы с командой дали честную.
Скоуп вернулся утверждённым. Оценка вернулась урезанной.

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

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

Я сделал! К сожалению, только через почти 2 месяца заказчик сам перенёс запуск продукта с 31 марта на 30 апреля (а позже и до 1 мая. Это финальная 😁). Но это лучше, чем ничего. Я долбил в одну точку, показывая, что сроки нереальные, и это сработало.

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

Где это не работает: если решение уже приняли на два уровня выше твоего контакта, документ ляжет на стол, у которого нет полномочий что-то менять. Тогда он перестаёт быть инструментом переговоров и становится страховкой на будущее. Писать всё равно стоит, просто по другой причине.

В следующей части: первый месяц и почему я потратил его вообще не на управление проектом.

Когда вам режут оценку, что вы пересматриваете первым делом, скоуп, сроки или что-то другое? Поделитесь в комментарии. Будет интересно почитать.