Дзен ПМа

всем привет
новая тема по свежим следам, так сказать.
Самое редкое качество, которое я вижу на всех уровнях в команде - это неготовность и нежелание брать на себя ответственность.
Почему так происходит и что можно с этим сделать?

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

Тут можно предположить рациональную модель в этом поведении:
"Если я ничего не решу - максимум скажут, что я вовремя эскалировал.
Если решу и ошибусь - буду отвечать какими то негативными для меня последствиями".

люди по умолчанию сужают свою зону ответственности до "минимум, за который меня точно не накажут". А так же "чем меньше я решаю сам, тем спокойнее живу"

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

Большинство членов команды никогда не учились:
- как взвешивать варианты;
- как считать риски;
- как формулировать решение и его обоснование;
- как выдерживать давление, когда решение кому-то не нравится.

В результате:
- разработчик лучше напишет сложный алгоритм, чем:предложит изменить UX или пересобрать флоу;
- PM легче напишет длинный статус-репорт, чем: возьмёт на себя позицию "делаем вот так, по таким причинам"

Когда нет навыка, любое серьёзное решение ощущается как прыжок в темноту.
И снова побеждает паттерн "передам ответственность на кого то другого"

В кратосрочной перспективе это работает, в долгосрочной - сильно снижает ценность специалиста. Его легче заменить, он превращается в "одного из". По сути, человек сам ограничивает свой рост и развитие.

Как можно помочь членам команды принимать решения и брать ответственность?

1) Ясно описать зоны ответственности и полномочий. То есть явно обсудить что такое поведение - ожидается, и что в случае ошибки это не приведет к негативным последствиям для человека
2) Не принимать проблемы, требовать вариантов. Не бросаться решать проблемы за членов команды, а коучить и менторить их находить и предлагать решения самим
3) Давать понятные рамки риска. В книге про культуру Нетфликс это описано как "управление контекстом". Например, там говорится, что решения до 1млн$ не требуют согласования вышестоящего руководства (Нетфликс берет только самых крутых спецов, поэтому у них это 1млн, у вас это может быть сильно меньше)
В случае обычной компании это может быть:,
"Ты можешь сам принимать решения, которые:
-не влияют на срок релиза больше чем на 1 день;
-не увеличивают бюджет более чем на X часов;
-не меняют юридические обязательства перед клиентом
4) Разбирать кейсы и превращать их в правила. Показывать на примерах, что можно было сделать и что это нормально и ожидается
5) Показывать личный пример. Если руководитель сам избегает решений; системно всё эскалирует выше, боится признать свои ошибки, то команда считывает это мгновенно и копирует.
6) Общая культура компании. Если руководство ищет крайних и виноватых, наказывает за попытки и ошибки, микроменеджит, то ожидать какой либо инициативы наивно, она будет исключительно у тех специалистов, которые абсолютно не боятся за свое место и четко знают себе цену, они привыкли работать автономно, таких не пугают негативные последствия. Однако таких людей единицы и стоит все же поднимать средний уровень.

Всем привет

Вторая серия Продолжение предыдущего поста по кейсу с клиентом.
Итак за эту неделю:
1) Клиент оплатил просроченный инвоис за сентябрь. На данный момент просрочки формальной нет, просто только сейчас согласовали октябрьский инвоис и выставили клиенту в среду, у клиента 7 бизнес дней на его оплату.
2) Клиент принял мое предложение о том, как получить себе больший бюджет на запуск первого крупного прод релиза:
- 10% скидка на инвоисы окт-дек
- бесплатное нагрузочное тестирование
- бесплатная дев поддержка (3rd level) 8 недель после релиза выделенным разработчиком (если мы делали с нормальным качеством и тестировали, то по идее эта поддержка в реальности будет минимальна)
Все эти меры направлены на поддержку клиента с запуском и демонстрирует нашу приверженность долгосрочным отношениям, при этом мы сохраняем приемлемую чистую прибыльность в 10-15% на остаток этого года

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

Должен сказать что отношения с клиентом и его свеженанятой командой (особенно СТО) остаются пока неидеальными и требуется определенная притирка и выработка эффективного формата взаимодействия и ожиданий, но это часть работы, это сложно, но абсолютно, на мой взгляд, решаемо.

Всем отличного дня!

всем привет

есть свежий кейс текущий, который прям очень показательный.
Итак, контекст:
достаточно крупный клиент, команда 10+ человек, работаем с ним с с марта над мобильным приложением для трейдинга. Контракт Т&M но есть там специфические условия - ограничение (cap) по бюджету и срокам, а также приложение тех требований, где описаны такие штуки как скорость ответа API, скорость загрузки приложения, аптайм, rate limiting, failover и тому подобное (хотя для большинства пунктов четко прописано что конкретные целевые показатели должны быть обсуждены позже и подписаны отдельно, я отбился как мог на пресейле)
И вот сроки и бюджет контракта остались позади еще в июле, мы продолжали доделывать приложение, все дополнительные работы согласуя с клиентом и с его одобрения. Регулярные демо клиенту каждые 2 недели, без каких либо серьезных замечаний.

Пришло время большой прод релиза в первых числах декабря (уже очень скоро), что называется, в люди. Приложение на 99% готово.

Внезапно клиент, с которым работали душа в душу, который хвалил все время нашу работу, начал агрессивно утверждать на звонке, что их не устраивает то, что мы делаем, что мы пытаемся их обмануть и что по контракту, оказывается, мы им должны кучу всего бесплатно, например нагрузочное и перформанс тестирование, мы же обещали в контракте поставить протестированное приложение (контракт T&M напомню, не фикса и без какой либо гарантии прописанной). С нашей стороны, при этом, явных косяков или задержек нет вообще, все вовремя и с качеством на уровне. На мои возражения, что ничего подобного в контракте нет, мне начали угрожать юристами и что мол, не стоит нарываться и вообще мы тут партнеры и тд
В личной беседе с одним из представителей клиента, он сказал что инвестор ограничил их по бабкам и если хотят бюджет на маркетинг - должны что то придумать.
Дополнительная важная информация: клиент не оплатил еще сентябрьский инвоис (т.е просрочка уже больше месяца при контрактных 7 днях), оспорил октябрьский само собой.
Что еще интереснее, что клиент при этом нанял на своей стороне СТО, продукта и даже какого то бекенд разработчика и перетянул код себе в git (может по контракту даже без оплаты)
Я выдвинул клиенту предложение как можно показать что мы долгосрочные партнеры с точки зрения бюджета и проекта.

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

а я в следующем серии посте озвучу что предложил я и какую реакцию получил от клиента и что было дальше)
Отличного дня!

Всем привет

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

Для клиентов из сша важнее всего, в порядке убывания
1) Референсы и социальное доказательство, доменная экспертиза
2) Фокус на бизнес-ценности, не на технологиях
3) Репутация и личный контакт
4) Скорость реакции и ответов
5) Прозрачная цена
6) Процесс и подход

для клиентов из европы (на одном уровне с тем, что выше)
1) знание регуляций и стандартов (коих в европе очень много в разных доменах)
2) Структурность и документация, они ценят последовательность
3) Безопасность и сертификация (всякие ISO, политики безопасности)

для ближнего востока
1) Персональное доверие и статус: решения принимают владельцы или board. Важно face value: титулы, опыт, презентабельность. Отправляйте презентации с фирменным дизайном, добавляйте лица команды и цитаты.
2) Региональная адаптация под местные требования, регуляции и системы (например, SAMA в KSA, CBUAE, CBK)
3) Фокус на дизайне и UX: Восточные клиенты часто хотят “premium look”. Покажите UI-примеры, а не только архитектуру.

Из моего личного опыта:
европейцы часто идут наиболее формальным путем, с большим количеством предварительных контактов, у них чаще формальные RFP и тендерные документы, четкие критерии выбора подрядчика
Клиенты из ближний восток быстрее принимают решения, имеют меньшее количество участников с их стороны, их команды часто мультикультурные или даже распределенные. Клиенты из эмиратов - часто хорошо образованные экспаты из разных стран востока и африки, которые имеют отличный бизнес опыт и представляют богатых инвесторов. Чаще всего головная компания будет из ОАЭ по понятным причинам что это финансовый центр.

Всем отличного дня!

6) Где то внизу этого списка идет: потенциальная команда - опытные разработчики и другие члены команды, возможность быстро собрать команду в 5-10 и больше человек, возможность замены в случае необходимости. Пост релизная поддержка, репутация и устойчивость компании.

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

Всем отличного дня!

Всем привет

Давайте поговорим о пресейле для клиентов из сша. Буду говорить из трендов, которые я видел за 2025й год в моей текущей компании по заказной разработке ПО.

Что обычно прилетает на вход:
1) полный формальный документ RFP с описанием всех частей: цель, общее описание, условия проведения отбора, расписание этапов и иногда дедлайнов проекта, общие функциональные и нефункциональные требования (не подробно), требования к поддержке и сертификациям вендора
Такое очень редко, кроме как когда компания ищет варианты именно на тендерных площадках.
2) документ описания проекта в виде pdf на 1-5 страниц. Функционал описан очень высокоуровнево, в общих чертах. Это обычно более бизнес документ описания приложения, иногда туда добавляются тех детали с помощью какой то ИИ (а иногда и весь документ сгенерирован ИИ)
3) заявки с формы на сайте. Обычно короткие, например " I'm looking for a connection provider for my fintech platform." или 1-2 предложения

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

Что важно для таких клиентов?
1) Релевантный опыт, само собой в идеале подтвержденный референсами и отзывами других клиентов, и в принципе доменная экспертиза связанная с запросом клиента
Для этого делаем упаковываем кейсы в страницы на сайте и в красивую коммуникацию, а также добавляем в конце в коммерческое предложение.

2) Скорость реакции и коммуникация. У меня были свежие кейсы когда клиент выбирал нас, потому что мы быстрее всех давали ему информацию о сроках, бюджетах и были готовы стартовать асап. В нескольких случях от первого звонка до подписания контракта проходило чуть больше одной недели. Если вы морозите клиента больше 2х недель, пока делаете свою подготовительную часть и оценку - шансы потерять клиента сильно повышаются.
Часто в коммуникации с клиентами из сша важно насколько вы понравились друг другу лично (имеется ввиду те люди, которые участвуют в звонках с клиентом или группой его представителей). Слабый английский, а также слишком формальный подход, когда восточноевропейцы сидят с угрюмыми лицами и разговаривают сухо - это все портит впечатление и снижает шансы, что выберут вас, а чаще всего именно так восточноевропейцы себя и ведут на звонках во всех компаниях, где я работал. Чтобы это исправить нанимают американских продавцов и аккаунт менеджеров или таких людей как я или архитекторов с хорошими коммуникативными навыками и английским, что совсем недешево и могут позволить себе только компании с 300+ сотрудников.

3) смотря с кем вы общатесь со стороны клиента, если это нетехнические бизнес люди - фокус ожидается на бизнес-ценности, не на технологиях. Им неинтересно и непонятно будет слушать про питон, джаву, реакт и aws. Но если на стороне клиента есть СТО или аналогичнный технарь - то каждому даем своё. Анализ стейкхолдеров тут надо делать сразу на старте.

4) Процесс и подход. Как вы будете управлять проектом, как будете обеспечивать прозрачность и результат. Сюда все рассказа про ваш "аджайл" процесс, репортинги, демо и так далее, плюс инженерные практики и практики обеспечения качества и безопасности. Сюда же можно отнести наличие сертификации ISO и знание местных (для клиента) регуляций и план соответствия им.

5) Стоимость. Обычно чем меньше компания - тем более чувствителен клиент к общей стоимости или к почасовой ставке. Для клиентов покрупнее само собой тоже важен бюджет но уже с учетом рисков получить низкое качество и задержки релиза, то есть они держат в уме ROI на это вложение в бизнес и предыдущие пункты выходят на первое место.
Если у нас есть доменная экспертиза, то мы фокусируемся не на цене, а на ценности, которую мы даем: мы дороже условных индусов, но зато мы сделаем быстрее и с более высоким качеством, попутно сможем посоветовать наиболее эффективные интеграции и решения исходя из предыдущего аналогичного опыта.

Всем привет

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

Было сразу очевидно что текущий процесс сильно неэффективен.
Посмотрели джиру, проанализировали доску, что увидели:
по control chart отчету джиры видно что средний cycle time у команды - 9 дней, от начала работы над задачей и до поставки, из них разработка - только 2 дня (!), еще 2 - ревью, день ожидания чтобы взять в тестирование и 4 дня в тестировании.

Стало понятно что работа итерациями приводит к тому, что большинство задач готово за первую неделю, а вторую неделю занимает тестирование, которое является узким местом на данном этапе (вместе с долгим ревью для мержа кода задачи)

Обсудили что надо:
- уходить от псевдо скрама и 2х недельных итераций (снять с команды давление конца итерации)
- ускорить прохождение ревью кода задачи когда он готов
- начинать тестирование сразу, а не ждать код фриза чтобы тестить их все сразу. Тестировать задачу и тестировать финальный релиз отдельно
- начинать переход на канбан
- начинать трекать метрики канбана для прогнозирования когда будет готово. Правда, для этого надо еще чтобы разработчики начали фиксировать фактическое время в задачу, чтобы метрики лучше отражали реальность.
- уйти в будущем от изначальных оценок (они все равно сильно неточны) за счёт использования cycle и lead time метрик по фактической скорости команды
- держать беклог приоритизированным чтобы можно было брать первую задачу сверху
- следить за wip лимитом и визуализировать заблокированные задачи, чтобы отслеживать причины блоков и время, неэффективно потраченное на такие случаи

ПМ будет отслеживать изменение средней cycle time и анализировать outliers (то есть задачи, которые заняли сильно больше среднего) на предмет уменьшения разброса времени завершения задач.
Также ПМ будет отслеживать узкие места на CFD (контрольной диаграмме потока), чтобы понимать динамику изменений времени по статусам по мере внедрения изменений. Все это позволит видеть, приносят ли они пользу

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

Всем отличной недели!

всем привет
буду писать чаще, но короче)

О важности фоллоу-апов, то есть писем после каких-то созвонов с клиентом, его командой или даже внутренних обсуждений (их можно в чат, но они тоже должны быть)

1) если их не писать, то через пару месяцев ответить на вопросы клиента почему так сделано, кто решил и с кем обсуждалось - превращается в веселый (нет) квест в попытках вспомнить. Если, в идеале, все фиксируется в документации, и изменения подтверждаются там клиентом - то так тоже можно, но это встречается ещё реже и только у крутых ПМ и БА
2) Фидбек клиента просто теряется и на очередном созвоне клиент спрашивает, а где эта штука/изменение, что я просил - и никто не помнит что он это просил, про это могут просто забыть. Разрабы думают что БА должен помнить или ПМ, а у них и так фрагментация фокуса и что-то просто выпадает, причем навсегда
3) Команда и клиент по разному поняли итоговые договоренности решение на звонке. Это чревато позже переделками и недовольством клиента
4) Потеря контекста. Новым членам команды очень сложно восстановить картину, что происходило до этого момента. Также очень сильно затрудняется передача проекта новому ПМ, если это необходимо
5) У клиента может сложиться впечатление что ПМ и, соответственно, команда - недостаточно профессиональны в коммуникации
6) команде сложнее следить за новыми задачами и откуда они взялись. Если им просто валятся тикеты, то это слегка демотивирует, особенно когда непонятна аргументация этих решений или запросов

Вот это все по следам боли от того, что нормальных фоллоуапов не было.

Бонусом шаблон для такого письма:
- Тезисный recap: что обсудили и решили.
- Список задач: владелец → срок.
- Открытые вопросы: кто отвечает и когда.
- Риски/зависимости: что может задержать.
- Следующие шаги: дата/время, формат следующего контакта.
- Ссылки/вложения: протокол, макеты, документы.
- Просьба подтвердить в ответ.
Лайфхак, формулируйте заключение письма в стиле "напишите если несогласны", а не "напишите что согласны". Таким образом, если они не ответили - вы можете считать что клиент со всем согласен.

Всем отличного дня!

всем привет

настало время поделиться свежей историей.
Для начала немного контекста: есть проект, дедлайн в 5 месяцев, команда без техлида, миддлы, в том числе и БА.
Есть ПМ, который закрывает все дыры собой, по сути, разбирается в каждой детали, сам с помощью ИИ помогает команде разбираться в интеграциях, много общается с клиентом по поводу мелких, но очень важных моментов в домене, которые надо учесть в приложении.
В итоге команда успевает в сроки, клиент доволен ПМом, все вроде хорошо
НО
ПМ уходит на другой проект и приходит новый.
Что он получает в проекте, который, на первы взгляд, вполне успешен:
- команда не разбирается в том, что она сделала. Разработчики банально не могут ответить на вопросы, откуда они берут те или иные цифры, которые отображаются в приложении. Само собой, оказывается, что берутся не те. Особенно грустно это выглядит когда на демо клиент задает вопрос, а в ответ - тишина
- документация скудная, даже часто ошибочная. Слабый БА был уволен на 4й месяц, миддл просто не смог вывезти нормально закрыть здесь всю часть бизнес-аналитика самостоятельно. Помощи не просил, да и ПМ все время пытался его тащить
- техдолг из-за не самых лучших решений миддлов по организации кода и интеграциям. Например, теперь падает кафка каждую неделю и никто не знает почему
- на любый вопросы клиента по результату команда по три дня ищет ответы, как у них что работает и почему так
- нет нормальных фоллоу-апов и фиксации запросов клиента во время демок
- команда на демке показывает старый билд и никто из команды на демке не понимает что это не последний билд, только через пару часов после провальной демки они это поняли
- к демо не готовятся, показывают сразу как пойдет. В итоге - две провальные демки подряд и полная потеря доверия клиента
- на вопрос, а почему у вас графики неправильные, ответ что мы графики не проверяли, просто что они отображаются и все (ну джун тестировщик, что с него взять)

То есть ПМ героически работал по 10-12 часов закрывая собой слабую команду, но в итоге ему не хватило времени сделать команду сильнее или хотя бы более самостоятельной. Вопрос с техлидом так и не был решен за 5 месяцев (хотя бюджет на это был), а то, что БА не справляется все таки стало больно очевидно ПМу на 5й месяц.
Сейчас клиент просить вернуть ПМа обратно, а он уже погрузился в другой проект и теперь будет, видимо, тащить сразу два, так же героически.

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

Напишите в комментариях, что вы думаете про такой подход ПМа к ведению проекта и что бы вы сделали на моем месте.
Отличного дня!

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

Проводя опять собеседования ПМов, в голову пришла такая мысль, как по разному кандидаты строят рассказ о себе и ответы на кейсовые вопросы типа "вот такая входная инфа, тебе надо стартовать проект, опиши свои действия".

Варианты ответов чаще всего абстрактные, не имеют структуры и конкретики и для меня это всегда проблема.
Вот в кратце заметки:
- кандидат говорит "мы" и описывает что будет делать команда, хотя я конкретно спросил опиши свои действия и хочу услышать что он конкретно будет делать. Например, я хочу услышать "проведу внутренний кикоф с командой, опишу проект, роли и задачи, затем организую кикоф с клиентом где я обсужу то-то и то-то"
- про себя кандидат часто описывает о чем был проект(ы) и компании, а не что он делал и как его организовал
- почти все миддлы знают только божественный скрам (и то не глубоко) и не знают почти ничего вне его. Редко кто может обьяснить канбан, кто-то мог прочитать пмбок но не может обьяснить как его применить. А уж про что-то еще шире типа Prince2, RUP и тд вообще даже не слышали обычно. Я не устаю повторять, что чем больше вариантов ПМ знает, тем лучше он сможет адаптировать процесс на проекте, взяв лучшее из других подходов, а не только из скрама. Например в RUP просто офигительно описан процесс работы с требованиями и стейкхолдерами
- мало кто говорит про матрицу или анализ стейкхолдеров, матрицу коммуникаций (хотя про саму коммуникацию все же говорят) и матрицу рисков. Обычно это все на минимальном уровне, по наитию и интуиции, не оформляя это формально, даже когда это имеет смысл.
- мало кто может назвать больше 2-3 метрик, редко кто понимает как прогнозировать дальше план-факта
- если кандидат говорит что использовал метод оценки PERT, то он чаще всего не понимает, что PERT все же больше чем 1 формула, которая дает 50% вероятности, а нужно еще считать сигму (кв.отклонение) чтобы получить 70+% вероятности, которую уже можно как то использовать
- деплоймент план и тд - это вообще считается проблемой техлида, как и инженерные практики.

В итоге, для меня это видится, что переход от миддла к сеньору у ПМа происходит только тогда, когда он отходит от чисто ручного интуитивного управления проектом и переходит на управление по данным.

Ручное управление работает только на небольших проектах, в проектах с командой 10+ человек это уже становится проблемой. То же самое касается умения адаптировать процесс. Обычный аутсорсный недоскрам ок работает тоже только на небольших проектах и сыпется с ростом размера команды

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

Всем отличного дня!

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

Есть проект, мобильное приложение для торговли акциями, простое достаточно, пользователю надо просто перевести деньги и купить акции в один клик (без лимиток и тд, просто маркет ордера). Надо разработать MVP.

Контракт time&material, с ограничением (cap) по макс бюджету, которое нельзя превышать, скажем 400 тысяч, а также с жестким дедлайном на 4 месяца разработки и 1 месяцем приемки.

На пресейле дали оценку в 320-350 тысяч и договорились на итоговый буфер до 400т.

ПМу досталась команда, далекая от идеала, где нет техлида, на беке есть пару миддлов и джун, на мобилке крепкие миддлы. Бизнес аналитик слабый, миддл минус, без релевантного опыта в домене (как и у разработчиков).

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

В итоге, по мере разработки вылезли такие проблемы/риски:

- аналитик пишет не очень качественные требования, что приводит к пробелам в имплементации
- миддлы на беке без опытного техлида часто превышают оценки, которые были на пресейле
- клиент постоянно вносит мелкие правки в интерфейс
- интеграции с брокером и KYC (Know Your Customer - проверка личности клиента с точки зрения фин регулятора, которую делает отдельная платформа) занимают в разы больше времени, чем было изначально запланировано, в том числе потому что клиент ожидает что команда настроит прод настройки в этих сторонних платформах, а в случае брокера еще и пройдет проверку для перехода из песочницы в прод, при этом брокер постоянно усложняет требования и просит дополнительные элементы
- в конце проекта становится понятно, что архитектура на беке неоптимальная и что постоянно всплывают проблемы неоптимизированности. Например, если интеграция по каким то причинам недоступна или не отвечает, то приложение просто перестает работать, даже если это просто не получены некоторые цифры для отображения

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

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

ПМ героически затыкает собой дыры в бизнес анализе и разбирает с разработчиками тех требования по интеграции.

ПМом были допущены некоторые ошибки в процессе ведения проекта. Как вы думаете, какие? Что можно и нужно было делать по другому в процессе ведения этого проекта?

Ну и что нужно делать теперь в этой ситуации?

Пишите свои мнения в комментариях, а я следующим постом опишу свой вариант ответа на эти вопросы.

Всем привет
Как же просто все было раньше с точки зрения умений и компетенций: прочитал кучу книг, статей и курсов, попрактиковался N лет (или 10 тыс часов) и всё - дальше ты эксперт на долгие годы.
Сейчас ты прокачался в чем-то - прошел годик другой и уже снова надо прокачиваться в чем то новом, чтобы просто остаться на том же уровне.
Как говорил персонаж Алисы в стране чудес (улитка вроде): "надо очень быстро бежать, чтобы просто оставаться на месте". И эта фраза точно отражает суть экспертности в IT.

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

С ПМами тоже все не стоит на месте - простую работу по анализу настроенной джиры может делать ИИ помощник, как и составлять планы и тд. Фокус сместился на такие вещи как: управление ожиданиями, коммуникацию, управление персоналом, переговоры, да и в принципе умение сформулировать ценность, хоть свою, хоть проекта.

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

В общем, прогресс идет огромными шагами, смотрите чтобы он вас не перешагнул!)
Всем отличного солнечного дня!

Примеры как это сделать:
1) описываем кучу бонусов, которые можно получить в дополнение к основному предложению в КП:
- кликабельный прототип
- темплейты документов
- поддержку и мониторинг
- маркетинг видео/демо
- UX ревью
- аудит существующего кода
- партнерские цены от сторонних (3rd party) интеграций
- Консультации с доменными экспертами на X часов
- дополнительные виды тестирования (нагрузочное, pentest и тд)
- lean canvas
- исследование ЦА, создание персон
2) гарантии по работе с нами, тут надо не мелочиться, например:
- Получите работающее приложение в течении первых 3х месяцев или мы вернем деньги (или вы не платите пока его не увидите)
- Если мы превысим верхнюю планку бюджета, то на каждый час работы сверху один беспплатно
- Если мы превысим верхнюю планку бюджета, то на часы выше этого скидка 50%
- Если вы не получили демо в первые 3 недели с начала проекта - мы вернем деньги
- Если вы не получили демо в первые 3 недели с начала проекта - вы не платите пока не получите
- если вы недовольны перформансом/работой любого члена команды, мы заменим его в течени 5 дней (или вы не будете платить за работу этого члена команды)
- если вам не понравились 3 концепции дизайна - мы делаем еще 5 бесплатно
- за каждое падение приложения в проде мы даем 150 часов рефакторинга бесплатно
- за каждый критический (critical/major) баг что пропустила наша команда тестирования мы даем 50 часов фиксов бесплатно
У гарантий есть точки активации, не буду сейчас на этом останавливаться
3) описываем типичные страхи клиента и как мы их будем избегать
- "Я буду понимать что происходит во время разработки" - вот как мы используем таск-трекер и планирование, куда у вас будет доступ, вот наши регулярные частые статус отчеты о прогрессе, вот наши регулярные демо промежуточного результата
- "Я получу не то приложение, которое хочу" - вот наши регулярные демо промежуточного результата, сбор фидбека, вот наш аналитик, который будет с тобой обсуждать все детали будущего приложения
- "Приложение будет низкого качества с большим количеством багов" - вот наш процесс тестирования и обеспечения качества
- "что то обязательно пойдет не так" - вот наша риск матрица и план работы с рисками, которые мы с тобой будет регулярно обсуждать
- "сторонние интеграции могут не подойти" - мы планируем интеграции в самом начале, чтобы понять это как можно раньше и сменить неподходящего провайдера на другого. Мы вообще планируем критически важные рискованные вещи на начало проекта
- "я превышу сроки или бюджет" - вот как мы работаем с прогнозированием, оценкой и вот наши гарантии на этот счет
и так далее, страхов больше, долго все описывать, общую идею, я думаю, вы поняли.

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

всем привет

Я уже больше 20 лет в IT и уже лет 15 как менеджер IT проектов.
До сих пор я все больше и больше вижу объём того, что я не знаю или умею недостаточно хорошо, поэтому не перестаю учиться и трачу на это большую часть своего условно свободного времени.
К чему это я?
Вот буквально сегодня у меня случился очередной инсайт "a-ha" момент, сейчас поделюсь.

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

Как обычно в аутсорс компании выбирают ценник, по которому продавать (рейт или общий бюджет, не важно)?
- посмотрели рейт конкурентов на рынке, взяли средний (немного выше нашей себестоимости но желательно чуть ниже прямых конкурентов),
- описали все что у конкурентов, но чуть лучше
имеем в итоге "окэй" ценностное предложение чуточку лучше конкурентов
НО
чем дешевле мы продаем, тем меньше нас ценят, тем хуже кажутся наши результаты, тем меньше клиенты эмоционально вовлечены.
А для нас это слабая переговорная позиция (а что вы хотели за такие деньги), меньше возможностей для бенефитов (потому что маржинальность сильно так себе)
И чем выше ЦЕНА тем выше ЦЕННОСТЬ для клиента. Цена КОММУНИЦИРУЕТ ценность заказчику. Мы берем больше, потому что мы даём больше.

Как показать клиенту, что мы даем больше?
- Мы описываем каков результат мечты для клиента
- Пунктуально выписываем все страхи/проблемы с которыми клиент сталкивается либо столкнется в будущем
- Идентифицируем их причину
- Облекаем проблемы в решения, которые мы и предлагаем, обрабатывая таким образом страхи покупателя
- Затем отбираем те решения которые несут большую ЦЕННОСТЬ для клиента, контролируя то, чтобы для нас затратными были только несколько решений

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

Самое важное, что я ищу в ПМе, на любом уровне - это надежность. Давайте поясню, о чем это я.
Я об умении брать на себя ответственность и доводить задачу до конца. Без "я не умею", "я не знаю" и точно "это не зависит от меня". Что то в стиле "у меня команда тупых джунов", "они не делают как я им говорю" или "клиент не хочет меня слушать".
Понятно, что нельзя все знать и все уметь, но кто-кто а ПМ точно не та позиция, где можно переложить ответственность. В случае, когда не хватает полномочий и тот, у кого они есть, поставлен вами в известность и делает выбор не использовать эти полномочия для решения проблемы у ПМа - это ок, объективно, ПМ делает то, что может, там где он есть, с тем, что имеет.
То есть, ПМ должен сделать все, что в его полномочиях, чтобы решить, а еще лучше, не допустить проблему. Я должен быть уверен. что ПМ не остановится на "и так сойдет", а сделает максимум или даже больше этого, если это необходимо.
Я должен быть уверен, что ПМ сделал все что было в его силах в каждой ситуации на проекте, а если не смог - то я был поставлен в известность сразу, а не когда ситуация превратилась в критическую. Он может прийти ко мне с описанием ситуации, но обязательно расскажет мне свой план, как он планирует действовать. Я не хочу и не буду делать за него, я могу ему подсказать, посоветовать, но я не буду забирать у него ответственность и не дам ему переложить на меня то, что он способен сделать сам.
Если он видит риск не справится потому что слишком много всего сразу, то это тоже нормально, он должен сам, я повторяю, сам поднять руку и сказать про это, а не рассказать это потом как оправдание.
Я так делал сам, я пытался кому то (себе в первую очередь) что то доказать беря на себя больше, чем мог вывезти - и потом расплачивался за это (мне пришлось покинуть компанию). Не надо играть в героя, это чревато ошибками и выгоранием.
Как руководитель, я не заинтересован в дополнительных рисках, потому что мой ПМ решил что он затащит все сам и будет крутой, но может быть и нет. Я не буду считать его слабым или плохим ПМом если он понимает риски перегруза и что если он ошибется, это будет не его проблема, а моя и компании, а он не много обычно теряет в итоге.
Подход "я сделал как смог, потому что {список причин}" или "я сделал как получилось" - это безответственный подход, показывающий как раз, что я не могу положиться на ПМа.

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

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

Подводя итог: спросите себя, сможете ли вы потом в резюме написать достижения на вашем текущем месте? сможете ли рассказать на собеседовании кейс про сложный проект или проблему, которую вы решили? Если да, то у вас хорошие шансы быть ценным при любом рынке.

"Когда компания переросла сайты на вп, но все еще не входит в топ 10 лидеров рынка" мой совет такой - выбрать нишу и сконцентрироваться исключительно на ней, предлагая именно глубокое понимание как решать проблемы и разрабатывать эффективные решения в этом домене. Например в компании где я сейчас, они сконцентрировались именно на финтехе и лиды приходят к нам именно как к экспертам в этом и мы можем обсуждать цену в последнюю очередь. Можем сменить фокус с цены, на ценность, которую клиент получает. Например: мы можем посоветовать с каким KYC провайдером стоит интегироваться, какую платежную систему выбрать, как работать с open banking, какой BaaS (Banking-as-a-Service) лучше всего закроет вопрос клиента в этом регионе, что должно быть в электронном кошельке, как сделать платформу для трейдинга и инвестирования. Наш опыт дает нам преимущество перед теми, кто предлагает просто дешевую разработку.

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

Если остались еще вопросы, которые хотелось бы чтобы я описал - смело пишите в комментарии.
Всем отличного дня!

Всем привет
На последний пост прислали интересный вопрос:
"На чем основывался твой выбор этих трех команд? Интересно взглянуть на выбор подрядчиков с точки зрения заказчика"

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

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

Маленькие компании (до ста человек плюс-минус) часто не имеют достаточного опыта, не могут самостоятельно закрыть и веб, мобилку, а даже если могут, то потом не смогут закрыть разработку на блокчейне и ИИ, а также не имеют возможности собрать команду 10+ человек без набора субподрядчиков. Основные риски таких компаний состоят в необходимости тратить дополнительное время на контроль их ресурсов и качества их работы. Это хороший вариант при маленьких бюджетах, поэтому я их тоже отмел.

Средние компании предоставляются хороший баланс стоимости и опыта, поэтому я искал именно такие компании.
Я ориентировался на рынок восточной европы именно из-за этого баланса. Рейты в среднем в этом сегменте на уровне 40-55$ в час, есть достаточное количество инхаус разработчиков уровня мидл и синьор, а также есть хорошие аналитики и ПМы с опытом работы на западные рынки.

Далее я спросил у чатагпт список компаний численностью от 200 до 500 человек с офисом в Польше, которые занимаются заказной аутсорс разработкой.
Из списка в примерно 10 компаний я выбрал 5 посмотрев их сайты и портфолио, а также учитывая что я знаю про эти компании (у многих были раньше офисы в Минске).
Затем зашел на сайты этих 5 компаний и отправил запрос в форму на сайте.
Одна компания на запрос, кстати, так и не ответила.
Вот эти 4 и участвовали в тендере. Одна компания отвалилась на старте тендера, дав понять что этот проект не подходит под их направление.

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

я составил план сравнения компаний, вот он
https://docs.google.com/document/d/14q4Reuwoij73D-60rTDC7bjH47B9jbkuvhG8ZrUZnAM/edit?usp=sharing

Теперь ко второй части вопроса
"По своим наблюдениям я могу сказать, что заказчики часто основываются на том, кто предложит наименьшую цену, даже когда речь идет о проектах с бюджетом в 2-4 миллиона (речь не о проектах на тильде за 100к). Из-за чего компании соглашаются на заведомо убыточные проекты и в процессе выполнения начинают «выкручивать» заказчику руки, раздувая бюджет, затягивая сроки или сдавая проект наспех с некачественным кодом и непродуманной архитектурой, пытаясь заработать на рефакторинге и доработках)
В общем, было бы интересно почитать твои мысли о том, как конкурировать на этом рынке, когда компания переросла сайты на вп, но все еще не входит в топ 10 лидеров рынка с огромным портфолио и сарафаном"

Конкурировать по наименьшей цене - значит конкурировать с двумя типами компаний: индусами и теми кто говорит минимальную цену, чтобы позже раскручивать доп часами и продаже джунов под видом сеньоров и подобными сомнительными техниками. Работает только со специфическими неопытными заказчиками с маленькими бюджетами.
В общем подход не очень эффективный, у кого то всегда дешевле и конверсия будет низкая.
Лучше конкурировать предлагая: полный спектр сервиса (end-to-end), доменную экспертизу, продавая решения а не руки и тд

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

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

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

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

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

Второе - состав команды. Две компании справились хорошо, предложенные команды были адекватного размера, где то в районе 10-12 человек в сумме, это включая ПМа, БА и тд. Одна компания предложила 23 человека, я не знаю как у них проходит пресейл и поэтому не могу придумать как они пришли к такому количеству человек на такой обьем работы

Третье - оценка бюджета. Две компании пришли к примерно одинаковому бюджету, третья же, поскольку почасовой рейт был примерно одинаковым, исходя из своей раздутой команды (аж два менеждера и солюшн архитектор фуллтайм) выдали оценку почти в 2 раза больше.

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

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

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

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

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

Ну и в завершение цитата из вакансии, что мне прислали в линкедине, немного говорит о том, что ожидать я думаю уже в ближайшее время в этой области:
“Обязанности:
-Формирование, обучение и управление командой prompt-аналитиков и организация их работы;
-Приём, анализ и обработка клиентских запросов с помощью нейросетей с целью получения драфтов эстимейтов и тех.заданий по задачам, их оценка, корректировка и возможное усреднение, делегирование итоговых эстимейтов/тех.заданий тех.команде и контроль их соблюдения последними;
-Участие в развитии внутренних процессов, связанных с применением ИИ в системной аналитике и разработке с целью повышения эффективности и производительности команд.”

Есть над чем подумать. Всем отличных выходных!

Всем привет!

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

Давайте обсудим.

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

Нужны какие то обьективные критерии работы непосредственно самого ПМа. Какие тут есть варианты?

Самы простой и самый логичный подход, который я в том числе использовал, это иметь как я его называю, деливери чеклист, то есть список всего того, что ПМ должен сделать в ходе проекта и там отмечать доказательства и подтверждения того, что он это сделал. Если что-то не сделал - вот тебе и критерий.

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

Еще один похожий способ, описанный вот тут:

https://www.cio.com/article/276198/project-management-an-objective-method-for-evaluating-project-managers-performance.html

Я его вкратце перескажу:

У ПМа есть 100 очков по завершению проекта. Очки снимаются за то, что было не так. Например: проект опоздал по срокам - минус 2 очка за каждую неделю просрочки. За каждый мажорный дефект в проде - минус 2 очка. Размер проекта тут также играет роль, то есть можно снимать больше очков за какие то более приоритетные стороны проекта, то есть если для клиента был очень важен дедлайн и мы его пропустили, то минус 5 очков, а не 2 за каждую неделю. С другой стороны, если получилось сделать лучше, чем планировали, то очки добавляются.

По сути это тот же чеклист, но с баллами.

Есть вот такой доумент с сотнями метрик для ПМа, можно выбрать свой набор, который подходит в вашей компании:

https://www.pmsolutions.com/audio/PM_Performance_and_Value_List_of_Measures.pdf

Что еще можно добавлять в микс выбранного подхода:

- KPI и прочие цели

- 360 фидбек от коллег, начальства и команды

- Результаты пост-мортем встреч по окончанию проекта

- Регулярный коучинг от более опытных коллег или деливери менеджера

- Делать разные критерии “весовыми”, то есть добавлять повышающие или понижающие коэффициенты при оценке списка того, что должен был сделать ПМ на проекте

- Обязательно устанавливать ожидания изначально, что такое “успех проекта”, как и в случае с разработчиками

- Поощрять за достижения и успехи, а не только карать

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

Всем отличных выходных!

Это достаточно много работы, но дает ощутимую базу аргументов, почему мы идем к человеку и даем ему предупреждение, что он на контроле и если так и дальше пойдет, то мы можем с ним расстаться. В зарубежных компаниях надо еще и прикрыть себя с юридической точки зрения (чтобы не получить иск за неправомерное увольнение) и мы делаем формальный PIP (Performance Improvement Plan). Он формален, но суть предупреждения от этого не меняется. Далее человек либо начинает работать лучше, либо у нас есть все доводы, чтобы с ним расстаться, при этом чтобы и для него не было это неожиданностью (“Почему вы мне раньше не сказали, что я плохо работаю! Я бы работал лучше! Я думал все норм”)

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

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

А как в вашей компании контролируют производительность членов команды?

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

Отличной наступающей недели!