3 истории из немецкого ИТ
В Германии любят процессы и правила. Моя компания по культуре ближе к американской и немцев у нас мало. Поэтому, кроме подробной должностной инструкции, я с этим пока мало сталкивался.
А вот в компании моего друга Мити полно немцев. Он поделился любопытными историями.
История 1
В один из спринтов к нам приходит фича, в которой есть бек и фронт. Вся команда по уши в других задачах, кроме одного разраба. А он как раз фуллстек. Сидим мы с тимлидом, и планируем следующий спринт:
- Петер, давай Алексу дадим эту фичу, он как раз освобождается.
- Можно, а кого поставим на бек?
- Его же и поставим, он же джаву тоже знает.
- Ну знает, и, что?
- Так если знает, то почему бы ему не сделать сразу и фронт, и бек? Будет быстрее, не надо двум девам синхронизироваться, все в одной голове.
- Митя, Алекс по контракту фронтэнд разработчик. Мы не можем давать фронтенд разработчикам задачи по беку, даже если они могут их сделать.
---
История 2
Наш СЕО любитель полировать интерфейс. Все время отбиваюсь от его улучшалок с пометкой срочно.
Но надо отдать ему должное, он старается уважать процессы разработки. Поэтому, когда мы перешли на юзер стори, задачи от него стали выглядеть так:
As a user I want to change the fonts, as they look ugly.
---
История 3
Я стараюсь максимально расписывать задачи, чтоб команда потом не бегала с вопросами. Добавляю контекст, бизнес ценность и все детали.
После очередного тех ревью, открываю один из тикетов и читаю: Rejected, as acceptance criteria are missing.
В задаче действительно пустые AC, но зато все описано в description. Думаю, ладно. Делаю копи-пэйст из description в AC и пишу тимлиду:
- Так пойдет?
- Да, теперь все ок, можем брать в работу.
---
Разумеется, не во всех компаниях будет так. Но квардратиш-практиш-гут культуры здесь правда, много.
В Германии любят процессы и правила. Моя компания по культуре ближе к американской и немцев у нас мало. Поэтому, кроме подробной должностной инструкции, я с этим пока мало сталкивался.
А вот в компании моего друга Мити полно немцев. Он поделился любопытными историями.
История 1
В один из спринтов к нам приходит фича, в которой есть бек и фронт. Вся команда по уши в других задачах, кроме одного разраба. А он как раз фуллстек. Сидим мы с тимлидом, и планируем следующий спринт:
- Петер, давай Алексу дадим эту фичу, он как раз освобождается.
- Можно, а кого поставим на бек?
- Его же и поставим, он же джаву тоже знает.
- Ну знает, и, что?
- Так если знает, то почему бы ему не сделать сразу и фронт, и бек? Будет быстрее, не надо двум девам синхронизироваться, все в одной голове.
- Митя, Алекс по контракту фронтэнд разработчик. Мы не можем давать фронтенд разработчикам задачи по беку, даже если они могут их сделать.
---
История 2
Наш СЕО любитель полировать интерфейс. Все время отбиваюсь от его улучшалок с пометкой срочно.
Но надо отдать ему должное, он старается уважать процессы разработки. Поэтому, когда мы перешли на юзер стори, задачи от него стали выглядеть так:
As a user I want to change the fonts, as they look ugly.
---
История 3
Я стараюсь максимально расписывать задачи, чтоб команда потом не бегала с вопросами. Добавляю контекст, бизнес ценность и все детали.
После очередного тех ревью, открываю один из тикетов и читаю: Rejected, as acceptance criteria are missing.
В задаче действительно пустые AC, но зато все описано в description. Думаю, ладно. Делаю копи-пэйст из description в AC и пишу тимлиду:
- Так пойдет?
- Да, теперь все ок, можем брать в работу.
---
Разумеется, не во всех компаниях будет так. Но квардратиш-практиш-гут культуры здесь правда, много.
Fix price flexible scope модель или как совместить бюджет и эджайл
Часто заказчики не знают точно чего хотят. У них есть лишь примерное видение продукта. Они буквально приходят и говорят: “Постройте нам что-то типо X за 100К”.
Fix price модель не подходит для такой работы, потому что по дороге будет слишком много изменений и проводить их через change request - боль для всех.
Time & material тоже не оч, ведь есть жесткий бюджет, превысить который клиент не может.
В этом случае на помощь приходит модель fixed price, flexible scope (FPFS). Иногда ее еще называют “T&M с крышкой”.
В ней мы берем лучшее от обеих моделей. Фиксируем бюджет, за который проект не выйдет, как в fixed price. При этом позволяем клиенту менять scope в лучших традициях T&M и эджайла.
Как это работает (коротко)
1️⃣ Выделяем 4 фичи из 10, без которых нельзя запустить проект. Обещаем их поставить.
2️⃣ Разрабатываем по скраму, Канбану, XP, да хоть стоя на голове.
3️⃣ Фокусируемся на 4 фичах и делаем их, скажем, за 60% бюджета
4️⃣ Оставшиеся 40% тратим на полировку, 6 других фич или новые фичи, которые осенили клиента по дороге.
Как это работает (подробно)
Flexible scope
Главное, что нужно сделать для FPFS модели - определить, какой scope нельзя выкинуть ни под каким соусом. С этим обычно проблем нет, клиенты даже на старте проекта знают, что вот эти 4 фичи нужны кровь из носа, а остальные можно пустить под нож (flexible scope).
Спецификация, как в FP не нужна, достаточно нескольких высокоуровневых критериев приемки. Их добавляем в контракт.
Начинаем проект, используя любой фреймворк. Делаем дискавери наших 4х фич и ставим им приоритет highest. На протяжении всего проекта они висят в топе беклога. С заказчиком четко проговариваем, что они идут в работу первыми.
Хотим добавить новые фичи? Не проблема - добро пожаловать в беклог.
Хотим приоритезировать новые фичи в следующем спринте? Мелочь за 2 стори поинта - может быть. Все остальное - извините, нет. Сначала мы сделаем наивысший приоритет, а потом все остальное.
Fixed price
Добавим щепотку проджект-менеджмента, чтобы уложиться в бюджет.
Для этого начинаем проект с груминга 4х фич. Запираемся с продактом в переговорке, и узнаем, как они должны работать. Затем оцениваем каждую и переводим эстимейты в деньги. Вуаля, теперь мы знаем, сколько бюджета уйдет на 4 фичи и сколько останется на дополнительные.
Иногда такое исследование выносят в отдельную фазу дискавери, если фич много или они сложные.
Оценку можно дать в часах, стори поинтах или спринтах. Любой формат, в котором потом будет удобно следить бюджетом.
Команда у нас постоянная, поэтому burndown (скорость съедания бюджета) тоже. Например,
100K (budget) / 10K (burndown) = 10 sprints (total budget)
Если из груминга мы узнали, что 4 фичи займут 6 спринтов, то еще 4 спринта у нас есть в запасе на остальной скоуп.
Теперь каждый спринт мы считаем, сколько денег потрачено и сколько работы осталось. Расход трекаем через release burndown chart, earned value или обычный эксель.
В конечном итоге FPFS - компромиссный вариант между FP и T&M. Он удобен и заказчику, и исполнителю.
В fixed price менеджер постоянно на нервах, думает, где бы срезать скоуп, чтобы попасть в бюджет. В time & material, наоборот, в проект затягивают любые фичи и доработки, лишь бы выжать побольше денег из клиента.
FPFS не тянет проект ни в какую из сторон, позволяя больше фокусироваться на ценности, которую мы поставляем с продуктом.
P.S. для продукта эту модель тоже можно использовать. Тут она подходит для проектов типо "надо запустить акцию к 8 марта".
Часто заказчики не знают точно чего хотят. У них есть лишь примерное видение продукта. Они буквально приходят и говорят: “Постройте нам что-то типо X за 100К”.
Fix price модель не подходит для такой работы, потому что по дороге будет слишком много изменений и проводить их через change request - боль для всех.
Time & material тоже не оч, ведь есть жесткий бюджет, превысить который клиент не может.
В этом случае на помощь приходит модель fixed price, flexible scope (FPFS). Иногда ее еще называют “T&M с крышкой”.
В ней мы берем лучшее от обеих моделей. Фиксируем бюджет, за который проект не выйдет, как в fixed price. При этом позволяем клиенту менять scope в лучших традициях T&M и эджайла.
Как это работает (коротко)
1️⃣ Выделяем 4 фичи из 10, без которых нельзя запустить проект. Обещаем их поставить.
2️⃣ Разрабатываем по скраму, Канбану, XP, да хоть стоя на голове.
3️⃣ Фокусируемся на 4 фичах и делаем их, скажем, за 60% бюджета
4️⃣ Оставшиеся 40% тратим на полировку, 6 других фич или новые фичи, которые осенили клиента по дороге.
Как это работает (подробно)
Flexible scope
Главное, что нужно сделать для FPFS модели - определить, какой scope нельзя выкинуть ни под каким соусом. С этим обычно проблем нет, клиенты даже на старте проекта знают, что вот эти 4 фичи нужны кровь из носа, а остальные можно пустить под нож (flexible scope).
Спецификация, как в FP не нужна, достаточно нескольких высокоуровневых критериев приемки. Их добавляем в контракт.
Начинаем проект, используя любой фреймворк. Делаем дискавери наших 4х фич и ставим им приоритет highest. На протяжении всего проекта они висят в топе беклога. С заказчиком четко проговариваем, что они идут в работу первыми.
Хотим добавить новые фичи? Не проблема - добро пожаловать в беклог.
Хотим приоритезировать новые фичи в следующем спринте? Мелочь за 2 стори поинта - может быть. Все остальное - извините, нет. Сначала мы сделаем наивысший приоритет, а потом все остальное.
Fixed price
Добавим щепотку проджект-менеджмента, чтобы уложиться в бюджет.
Для этого начинаем проект с груминга 4х фич. Запираемся с продактом в переговорке, и узнаем, как они должны работать. Затем оцениваем каждую и переводим эстимейты в деньги. Вуаля, теперь мы знаем, сколько бюджета уйдет на 4 фичи и сколько останется на дополнительные.
Иногда такое исследование выносят в отдельную фазу дискавери, если фич много или они сложные.
Оценку можно дать в часах, стори поинтах или спринтах. Любой формат, в котором потом будет удобно следить бюджетом.
Команда у нас постоянная, поэтому burndown (скорость съедания бюджета) тоже. Например,
100K (budget) / 10K (burndown) = 10 sprints (total budget)
Если из груминга мы узнали, что 4 фичи займут 6 спринтов, то еще 4 спринта у нас есть в запасе на остальной скоуп.
Теперь каждый спринт мы считаем, сколько денег потрачено и сколько работы осталось. Расход трекаем через release burndown chart, earned value или обычный эксель.
В конечном итоге FPFS - компромиссный вариант между FP и T&M. Он удобен и заказчику, и исполнителю.
В fixed price менеджер постоянно на нервах, думает, где бы срезать скоуп, чтобы попасть в бюджет. В time & material, наоборот, в проект затягивают любые фичи и доработки, лишь бы выжать побольше денег из клиента.
FPFS не тянет проект ни в какую из сторон, позволяя больше фокусироваться на ценности, которую мы поставляем с продуктом.
P.S. для продукта эту модель тоже можно использовать. Тут она подходит для проектов типо "надо запустить акцию к 8 марта".
Как я попал в айти
Иногда этот вопрос задают в комментах, поэтому давайте всем расскажу.
🎓Универ
Я закончил Мех-Мат БГУ. Из него в ИТ мне пригодились 2 навыка:
▫️базовое понимание программирования. Могу перемножить 2 матрицы на С++ и джаве. От современного программирования это далеко, но принципы знать полезно.
▫️умение находить обходные пути. Этот скилл рос с каждым экзаменом, ведь сдать функциональный анализ очень сложно, когда ты его не понимаешь. Значит надо искать воркэраунд, например: ходить на все пары, написать шпоры или сдать все лабы (взяток не существовало). Иногда этого хватало, чтобы получить минимальную оценку и не вылететь.
🏦 Банк
На 4 курсе я устроился в ИТ отдел банка. У нас была десктопная программа Bank-IT, типо банковской апы на телефоне, только для юрлиц. Я ездил устанавливать ее на компьютеры, объяснял, как делать платежи и отвечал на звонки, когда у клиентов что-то не работало. Клиенты были очень разные - от директоров птицефабрик до парикмахеров-ИПэшников.
В банке нас очень дрючили за то, что сейчас называют customer success. Надо было не просто ответить на вопрос, а помочь клиенту решить проблему, чтобы он ушел от тебя довольным. До сих пор помню, как начальник проверял, улыбаюсь ли я во время разговора по телефону. Такой трюк действительно делает речь более дружелюбной, даже если на душе у тебя предстоящий экзамен по матану.
После 5 курса надо было выбирать, чем заниматься в жизни. Моя тогдашняя девушка работала бизнес-аналитиком. Писала спеку для каких-то жутких научных программ, кажется. Ее работа казалась мне простой - разговаривай с людьми, да записывай в ворде их хотелки.
Тогда я решил, что тоже так могу, и нашел свою первую работу бизнес-аналитиком за 400$ в месяц. Это было 24 июня 2013 года. В почте мейлру даже нашелся тот самый первый оффер.
Должен сказать, что устроиться в ИТ тогда было в разы проще - вакансий было больше, а кандидатов меньше.
🧑💻 Веб-студия
Быстро выяснилось, что аналитик в веб студии на 10 человек, это не только требования к сайтами. Это еще и контекстная реклама, собеседования сеошников, пресейл, какие-то акты приемки. Все это дало неплохой кругозор того, как устроен сервисный ИТ-бизнес.
В это время типичным проектом для нас был сайт компании, которая сажает газон. Или сдаёт напрокат экскаваторы. Моей работой было понять, какие странички нужны клиенту, выбрать шаблон на джумле, наполнить его контентом от клиента (или придумать 😉) и сделать программистам список кастомизаций.
Еще я настраивал контекстную рекламу в гугле и яндексе. Помню как чел, которому мы за 300$ в месяц настроили рекламу, иногда звонил и говорил «Рома хули у меня сегодня мало звонков?». Тоже школа управления ожиданиями своего рода.
Правда, как аналитик я рос слабо. Проект на 200 часов считался уже серьезным предприятием, а на такой мелочи сильно не прокачаешься. Самое серьезное, что я делал, были спеки для внутренней CRM-ки (так и не запустили) и UX-прототип для большого музыкального магазина.
Требования и интерфейсы мне нравились, но в компании не было ПМа.
👼 PM is born
Через год я осмелел и начал спрашивать программистов «почему вы сделали не то, что в тз?». Иногда они соглашались что-то исправить и тогда я спрашивал «сколько это займет?». Через пару дней я настигал их с «ну что, еще не готов?». Так, роль ПМа сама собой легла на мои плечи. Теперь я больше отвечал за успех проекта и сроки-бюджеты.
Оценка моего скила доросла до космических 1200$ в мес. Для стоимости жизни в Беларуси тех лет, это был успех (так мне казалось).
Тогда я решил, что пора выходить на новый уровень, и стал искать работу посерьезнее.
Пожалуй, самой крутой конторой в то время считался Wargaming, которая делала культовую игру World of Tanks. Я подавался несколько раз и однажды даже прорвался на собеседование на релиз-менеджера. Но мои технические знания были слабыми, поэтому получил ожидаемый отказ.
Однако их хватило для Softeq - первой аутсорсинговой компании, в которой я работал (из двух). Тут уже были хорошие проекты по разработке на 3-5К часов, но это уже совсем другая история.
Иногда этот вопрос задают в комментах, поэтому давайте всем расскажу.
🎓Универ
Я закончил Мех-Мат БГУ. Из него в ИТ мне пригодились 2 навыка:
▫️базовое понимание программирования. Могу перемножить 2 матрицы на С++ и джаве. От современного программирования это далеко, но принципы знать полезно.
▫️умение находить обходные пути. Этот скилл рос с каждым экзаменом, ведь сдать функциональный анализ очень сложно, когда ты его не понимаешь. Значит надо искать воркэраунд, например: ходить на все пары, написать шпоры или сдать все лабы (взяток не существовало). Иногда этого хватало, чтобы получить минимальную оценку и не вылететь.
🏦 Банк
На 4 курсе я устроился в ИТ отдел банка. У нас была десктопная программа Bank-IT, типо банковской апы на телефоне, только для юрлиц. Я ездил устанавливать ее на компьютеры, объяснял, как делать платежи и отвечал на звонки, когда у клиентов что-то не работало. Клиенты были очень разные - от директоров птицефабрик до парикмахеров-ИПэшников.
В банке нас очень дрючили за то, что сейчас называют customer success. Надо было не просто ответить на вопрос, а помочь клиенту решить проблему, чтобы он ушел от тебя довольным. До сих пор помню, как начальник проверял, улыбаюсь ли я во время разговора по телефону. Такой трюк действительно делает речь более дружелюбной, даже если на душе у тебя предстоящий экзамен по матану.
После 5 курса надо было выбирать, чем заниматься в жизни. Моя тогдашняя девушка работала бизнес-аналитиком. Писала спеку для каких-то жутких научных программ, кажется. Ее работа казалась мне простой - разговаривай с людьми, да записывай в ворде их хотелки.
Тогда я решил, что тоже так могу, и нашел свою первую работу бизнес-аналитиком за 400$ в месяц. Это было 24 июня 2013 года. В почте мейлру даже нашелся тот самый первый оффер.
Должен сказать, что устроиться в ИТ тогда было в разы проще - вакансий было больше, а кандидатов меньше.
🧑💻 Веб-студия
Быстро выяснилось, что аналитик в веб студии на 10 человек, это не только требования к сайтами. Это еще и контекстная реклама, собеседования сеошников, пресейл, какие-то акты приемки. Все это дало неплохой кругозор того, как устроен сервисный ИТ-бизнес.
В это время типичным проектом для нас был сайт компании, которая сажает газон. Или сдаёт напрокат экскаваторы. Моей работой было понять, какие странички нужны клиенту, выбрать шаблон на джумле, наполнить его контентом от клиента (или придумать 😉) и сделать программистам список кастомизаций.
Еще я настраивал контекстную рекламу в гугле и яндексе. Помню как чел, которому мы за 300$ в месяц настроили рекламу, иногда звонил и говорил «Рома хули у меня сегодня мало звонков?». Тоже школа управления ожиданиями своего рода.
Правда, как аналитик я рос слабо. Проект на 200 часов считался уже серьезным предприятием, а на такой мелочи сильно не прокачаешься. Самое серьезное, что я делал, были спеки для внутренней CRM-ки (так и не запустили) и UX-прототип для большого музыкального магазина.
Требования и интерфейсы мне нравились, но в компании не было ПМа.
👼 PM is born
Через год я осмелел и начал спрашивать программистов «почему вы сделали не то, что в тз?». Иногда они соглашались что-то исправить и тогда я спрашивал «сколько это займет?». Через пару дней я настигал их с «ну что, еще не готов?». Так, роль ПМа сама собой легла на мои плечи. Теперь я больше отвечал за успех проекта и сроки-бюджеты.
Оценка моего скила доросла до космических 1200$ в мес. Для стоимости жизни в Беларуси тех лет, это был успех (так мне казалось).
Тогда я решил, что пора выходить на новый уровень, и стал искать работу посерьезнее.
Пожалуй, самой крутой конторой в то время считался Wargaming, которая делала культовую игру World of Tanks. Я подавался несколько раз и однажды даже прорвался на собеседование на релиз-менеджера. Но мои технические знания были слабыми, поэтому получил ожидаемый отказ.
Однако их хватило для Softeq - первой аутсорсинговой компании, в которой я работал (из двух). Тут уже были хорошие проекты по разработке на 3-5К часов, но это уже совсем другая история.
P.S. Одной из причин, почему меня взяли в Softeq, был сильный английский. Коротко расскажу, как я его выучил:
- в школе 6 раз в неделю;
- потом в универе 4 года;
- ездил в штаты 4 раза, к клиентам и по work & travel;
- музыка, фильмы, конечно;
Когда я уже попал в Softeq, все клиенты и пользователи здесь говорили на английском. Это очень раскачало аудирование - важнейший навык для ПМа. Благодаря ему мне легко договариваться с клиентами, т.к. я хорошо улавливаю, что говорят индийцы, французы, бразильцы.
Кроме шотландцев, их хрен разберешь.
2013 >>
- в школе 6 раз в неделю;
- потом в универе 4 года;
- ездил в штаты 4 раза, к клиентам и по work & travel;
- музыка, фильмы, конечно;
Когда я уже попал в Softeq, все клиенты и пользователи здесь говорили на английском. Это очень раскачало аудирование - важнейший навык для ПМа. Благодаря ему мне легко договариваться с клиентами, т.к. я хорошо улавливаю, что говорят индийцы, французы, бразильцы.
Кроме шотландцев, их хрен разберешь.
2013 >>
Что такое программа
Я теперь работаю программным менеджером. А раз прошел испытательный срок, значит могу рассказать вам, что такое программа.
Программа - это мега-проект, у которого под капотом несколько проектов поменьше, объединенных одной целью, которые делают несколько команд.
Например:
1️⃣Мигрировать базу пассажиров Uber с Amazon на Oracle. Представьте сколько команд пользуются данными пассажиров в убере, десятки! Даже просто найти эти команды уже непростая задача.
Еще с ними нужно договориться о сроках, создать гайдланы по миграции, сделать площадку по поддержке, рассчитать новый билинг, запланировать тушение старой базы. Все это - часть программы.
2️⃣Сделать фичу кошелек в Wolt.
В такой программе тоже десятки команд: платежи, маркетинг, комплайенс, CRM, customer success…и это мы даже до инжиниринга не дошли :)
В небольших компаниях программы встречаются редко. А вот когда над одной инициативой работает много команд, их нужно постоянно синхронизировать и разруливать между ними зависимости. Здесь и появляются программы.
Программы обычно долгие, месяцев 6 минимум. На таком скейле невозможно все продумать заранее, изменения бывают часто. Поэтому, как и в продукте, важно иметь хорошую стратегию. Ритм жизни программы вообще похож на продуктовый. У тебя есть какая-то большая цель и ты к ней бежишь, попутно выясняя дорогу.
В следующих постах расскажу в чем отличие программы от проекта, и что делает програм-менеджер.
Я теперь работаю программным менеджером. А раз прошел испытательный срок, значит могу рассказать вам, что такое программа.
Программа - это мега-проект, у которого под капотом несколько проектов поменьше, объединенных одной целью, которые делают несколько команд.
Например:
1️⃣Мигрировать базу пассажиров Uber с Amazon на Oracle. Представьте сколько команд пользуются данными пассажиров в убере, десятки! Даже просто найти эти команды уже непростая задача.
Еще с ними нужно договориться о сроках, создать гайдланы по миграции, сделать площадку по поддержке, рассчитать новый билинг, запланировать тушение старой базы. Все это - часть программы.
2️⃣Сделать фичу кошелек в Wolt.
В такой программе тоже десятки команд: платежи, маркетинг, комплайенс, CRM, customer success…и это мы даже до инжиниринга не дошли :)
В небольших компаниях программы встречаются редко. А вот когда над одной инициативой работает много команд, их нужно постоянно синхронизировать и разруливать между ними зависимости. Здесь и появляются программы.
Программы обычно долгие, месяцев 6 минимум. На таком скейле невозможно все продумать заранее, изменения бывают часто. Поэтому, как и в продукте, важно иметь хорошую стратегию. Ритм жизни программы вообще похож на продуктовый. У тебя есть какая-то большая цель и ты к ней бежишь, попутно выясняя дорогу.
В следующих постах расскажу в чем отличие программы от проекта, и что делает програм-менеджер.
Чем программа отличается от проекта
Програм-менеджеры не любят, когда их сравнивают с проджектами. Я не вижу здесь большой драмы, по-моему, это очень похожие роли. Равно как похожи программы и проекты.
И тут и там есть стейкхолдеры, скоуп, расписание, риски, видимые границы завершения (в отличие от продукта, например).
Программа - это проект на стероидах. Окей, вместо 6 человек, которые делают 5 фич, будет 60 человек и 50 фич. Но главное не меняется - им все еще нужно поставить ценность в каких-то ограничениях.
С ростом масштаба появляются новые проблемы, которые почти не заметны в проекте - синхронизация. Помните, как два человека в одной команде порой по-разному воспринимают одну и ту же задачу? А теперь представьте, что у вас 60 человек и все работают в изолированных группах (командах).
И вот как раз здесь, появляется существенное, на мой взгляд, различие:
❗️Программам нужен продуктовый подход.
Из-за того, что программы большие, неповоротливые и долгие им нужен какой-то общий фундамент - цели, метрики, стратегия. Это помогает синхронизировать народ и принимать решения в едином контексте. В проекте без этого можно обойтись (хотя тоже хорошо бы иметь), но на скейле это становится критично.
Я вам этого всего, конечно, не говорил :). Если где-то спросят о разнице между проектом и программой, отвечайте примерно так:
Програм-менеджеры не любят, когда их сравнивают с проджектами. Я не вижу здесь большой драмы, по-моему, это очень похожие роли. Равно как похожи программы и проекты.
И тут и там есть стейкхолдеры, скоуп, расписание, риски, видимые границы завершения (в отличие от продукта, например).
Программа - это проект на стероидах. Окей, вместо 6 человек, которые делают 5 фич, будет 60 человек и 50 фич. Но главное не меняется - им все еще нужно поставить ценность в каких-то ограничениях.
С ростом масштаба появляются новые проблемы, которые почти не заметны в проекте - синхронизация. Помните, как два человека в одной команде порой по-разному воспринимают одну и ту же задачу? А теперь представьте, что у вас 60 человек и все работают в изолированных группах (командах).
И вот как раз здесь, появляется существенное, на мой взгляд, различие:
❗️Программам нужен продуктовый подход.
Из-за того, что программы большие, неповоротливые и долгие им нужен какой-то общий фундамент - цели, метрики, стратегия. Это помогает синхронизировать народ и принимать решения в едином контексте. В проекте без этого можно обойтись (хотя тоже хорошо бы иметь), но на скейле это становится критично.
Я вам этого всего, конечно, не говорил :). Если где-то спросят о разнице между проектом и программой, отвечайте примерно так:
Как понять, кто перформер, а кто нет
В небольшой команде все варятся в общем информационном пузыре. Народу мало, проектов мало, все на виду. Если новый лид айосник оказался лодырем, это быстро станет заметно.
В большой не так, здесь легко затеряться.
Лид айсоник может каждые 4 месяца прыгать с проекта на проект. И тогда подбить его перфоманс становится трудно, т.к. у тебя, как у его менеджера просто нет инфы, как он переоформил. Ты, конечно, поспрашиваешь фидбека у других людей, кто с ним работал, но тут свои риски.
Для тех, кто делает пипл менеджмент такая непрозрачность, это большая проблема.
Есть классный инструмент, который ее решает - Small Improvements. Его главный функционал - написать публичный комплимент о коллеге.
В линкедине вы наверняка видели посты со словом Kudos, когда люди хвалят друг друга и выражают признательность. Тут то же самое.
Лид айосник сделал классный tech proposal новой фичи - напиши ему Kudos, чтобы все знали, какой он красавчик. Менеджер из другой команды быстро сделал то, что вы просили (в отличие от других менеджеров-бездельников) - Kudos. Продакт провел крутой воркшоп без воды и соплей - Kudos. Так ты “хвалишь при всех”, причем сразу на всю компанию.
Все кудосы собираются в общую ленту. Можно смотреть, какие кудосы получили твои ребята. Можно смотреть, кто тащер в других командах.
Люди не станут просто так хвалить друг друга за фигню (если вы не привяжите кудосы к kpi, конечно). Если пишут, то за дело. Получается честный, справедливый и адресный фидбек.
Теперь, если к тебе в команду месяц назад перешел айосник и надо сделать его годовое ревью, у тебя есть качественный источник информации.
В Small improvements кроме Kudos есть еще функционал 1-1, перф ревью, 360 фидбек и всякое такое. Но наверняка, есть и другие хорошие сервисы с Kudos. Напишите в комментарии, если пользовались такими.
-----------------
UPD: в комментах многие пишут, что в их компании такой подход не работает (спасибо, что делитесь опытом 🤝). Кудосы получают не реальные герои, те, кто общается с большим количеством людей или просто более говорливые и харизматичные люди.
Я думаю, это вопрос культуры. А любая культура всегда идет сверху.
Чтобы система работала, менеджеры должны:
- хвалить за успехи и результаты, а не ожидаемую работу или просто "спасибо";
- постоянно писать кудосы своей команде;
- напоминать писать кудосы другим;
Здесь тот же принцип, что и с пустой джирой, опозданием на встречи и невыполнением любых обещаний: сначала сам начни делать, а потом проси команду.
В небольшой команде все варятся в общем информационном пузыре. Народу мало, проектов мало, все на виду. Если новый лид айосник оказался лодырем, это быстро станет заметно.
В большой не так, здесь легко затеряться.
Лид айсоник может каждые 4 месяца прыгать с проекта на проект. И тогда подбить его перфоманс становится трудно, т.к. у тебя, как у его менеджера просто нет инфы, как он переоформил. Ты, конечно, поспрашиваешь фидбека у других людей, кто с ним работал, но тут свои риски.
Для тех, кто делает пипл менеджмент такая непрозрачность, это большая проблема.
Есть классный инструмент, который ее решает - Small Improvements. Его главный функционал - написать публичный комплимент о коллеге.
В линкедине вы наверняка видели посты со словом Kudos, когда люди хвалят друг друга и выражают признательность. Тут то же самое.
Лид айосник сделал классный tech proposal новой фичи - напиши ему Kudos, чтобы все знали, какой он красавчик. Менеджер из другой команды быстро сделал то, что вы просили (в отличие от других менеджеров-бездельников) - Kudos. Продакт провел крутой воркшоп без воды и соплей - Kudos. Так ты “хвалишь при всех”, причем сразу на всю компанию.
Все кудосы собираются в общую ленту. Можно смотреть, какие кудосы получили твои ребята. Можно смотреть, кто тащер в других командах.
Люди не станут просто так хвалить друг друга за фигню (если вы не привяжите кудосы к kpi, конечно). Если пишут, то за дело. Получается честный, справедливый и адресный фидбек.
Теперь, если к тебе в команду месяц назад перешел айосник и надо сделать его годовое ревью, у тебя есть качественный источник информации.
В Small improvements кроме Kudos есть еще функционал 1-1, перф ревью, 360 фидбек и всякое такое. Но наверняка, есть и другие хорошие сервисы с Kudos. Напишите в комментарии, если пользовались такими.
-----------------
UPD: в комментах многие пишут, что в их компании такой подход не работает (спасибо, что делитесь опытом 🤝). Кудосы получают не реальные герои, те, кто общается с большим количеством людей или просто более говорливые и харизматичные люди.
Я думаю, это вопрос культуры. А любая культура всегда идет сверху.
Чтобы система работала, менеджеры должны:
- хвалить за успехи и результаты, а не ожидаемую работу или просто "спасибо";
- постоянно писать кудосы своей команде;
- напоминать писать кудосы другим;
Здесь тот же принцип, что и с пустой джирой, опозданием на встречи и невыполнением любых обещаний: сначала сам начни делать, а потом проси команду.
Английские сокращения, которые встретятся на работе за рубежом
🇬🇧 ETA - expected time of arrival.
Начнем с любимого вопрос менеджеров - когда будет готово?
🇬🇧EOD - end of day.
- Какой ETA у этой фичи?
- EOD.
Аналогично, EOW - end of the week.
🇬🇧СС - carbon copy.
Никто не расшифровывает СС, а просто ставят в копию:
Вы охренели, не сделали мою часть проекта! СС @Василий_Петрович.
🇬🇧 FTE - full-time employee.
Если в команде 2 разработчика фуллтайм, и 1 на пол-ставки, то говорят что в команде 2,5 FTE.
🇬🇧PTO - paid time off.
Не знаю, честно говоря, зачем тут делать упор на paid, но часто слышу, что так говорят. Особенно, в контексте parent leave.
🇬🇧OOO - out of the office.
На следующей неделе я буду в отпуске, так что все вопросики направляйте Василию Петровичу и держите меня в СС.
🇬🇧BRB - be right back.
Когда на звонке все сидят с включенными камерами, а к тебе в дверь звонит курьер и надо его встретить. Тогда ты пишешь в чате brb, как бы шепча всем присутствующим на ушко “я отойду на минутку, ща буду”, чтобы никто не дай бог не подумал, что тебе просто надоело слушать.
🇬🇧TBD - to be determined.
Так можно написать, когда, например, вы определились с датой релиза для фазы 1, а вот фаза 2 пока хз (TBD) когда будет готова.
🇬🇧WDYT? - what do you think?
Помню, как впервые увидел это в чате и подумал, wtf? Потом погуглил, и узнал, что это просто сокращенное что думаешь?
🇬🇧LMK - let me know.
Почти то же, что и wdyt.
🇬🇧FYI - for your information.
К твоему сведению….только не такое формальное.
🇬🇧IDK - I don’t know.
Я хз кароч.
🇬🇧AFAIK - as far as I know.
Насколько я знаю.
🇬🇧nvm - nevermind.
Забей.
🇬🇧ty, thx - thank you, thanks.
Если thx еще можно догадаться что такое, то с ty я орал, когда узнал что это просто спасибо.
🇬🇧dm - direct messages.
Цену отправил в лс (dm).
🇬🇧 ETA - expected time of arrival.
Начнем с любимого вопрос менеджеров - когда будет готово?
🇬🇧EOD - end of day.
- Какой ETA у этой фичи?
- EOD.
Аналогично, EOW - end of the week.
🇬🇧СС - carbon copy.
Никто не расшифровывает СС, а просто ставят в копию:
Вы охренели, не сделали мою часть проекта! СС @Василий_Петрович.
🇬🇧 FTE - full-time employee.
Если в команде 2 разработчика фуллтайм, и 1 на пол-ставки, то говорят что в команде 2,5 FTE.
🇬🇧PTO - paid time off.
Не знаю, честно говоря, зачем тут делать упор на paid, но часто слышу, что так говорят. Особенно, в контексте parent leave.
🇬🇧OOO - out of the office.
На следующей неделе я буду в отпуске, так что все вопросики направляйте Василию Петровичу и держите меня в СС.
🇬🇧BRB - be right back.
Когда на звонке все сидят с включенными камерами, а к тебе в дверь звонит курьер и надо его встретить. Тогда ты пишешь в чате brb, как бы шепча всем присутствующим на ушко “я отойду на минутку, ща буду”, чтобы никто не дай бог не подумал, что тебе просто надоело слушать.
🇬🇧TBD - to be determined.
Так можно написать, когда, например, вы определились с датой релиза для фазы 1, а вот фаза 2 пока хз (TBD) когда будет готова.
🇬🇧WDYT? - what do you think?
Помню, как впервые увидел это в чате и подумал, wtf? Потом погуглил, и узнал, что это просто сокращенное что думаешь?
🇬🇧LMK - let me know.
Почти то же, что и wdyt.
🇬🇧FYI - for your information.
К твоему сведению….только не такое формальное.
🇬🇧IDK - I don’t know.
Я хз кароч.
🇬🇧AFAIK - as far as I know.
Насколько я знаю.
🇬🇧nvm - nevermind.
Забей.
🇬🇧ty, thx - thank you, thanks.
Если thx еще можно догадаться что такое, то с ty я орал, когда узнал что это просто спасибо.
🇬🇧dm - direct messages.
Цену отправил в лс (dm).
Как окупаются тимбилдинги и корпоративы
На первой работе я думал, вау, компания так балует сотрудников, кормит нас красной рыбкой на корпоративе. Затем оказалось, что в некоторых фирмах по пятницам пиво и пиццу! Это казалось уже каким-то социальным экспериментом.
На деле такие ивенты нужны в первую очередь самой компании. Они повышают лояльность и вовлеченность сотрудников. Народ больше дружит, эффективнее работает и реже увольняется. И это все за каких-то 100-200 баксов на человека в год!
Недавно я устраивал тимбилдинг для своего отдела. Через час я слышу, что половина людей говорит о работе. Уже под другим градусом откровенности, но все же.
По той же причине топ компании строят мега-крутые офисы. Идея в том, чтобы люди проводили в них как можно больше времени. Когда у тебя под рукой спортзал, ресторан и массаж, то из офиса как будто и незачем уезжать. Все есть в кампусе. Ну а если вдруг придет хорошая идея по работе, то ты как раз уже в подходящей обстановке.
В общем, компания вкладывается в плюшки, чтобы ты поработал лишние 30 минут. Или познакомился с коллегой получше и стал более эффективным. Для кого-то это справедливая сделка, просто надо понимать, что если ты не платишь за товар (красную рыбку на корпоративе), то ты и есть товар.
Некоторые ребята, считают ее не такой справедливой и рассуждают так. Раз тимбилдинг, это рабочий ивент, то давайте проводить его в рабочее время. Но тут уже у компании юнит-экономика не сходится.
Я смотрю на тимбилдинги, как на возможность понетворкать (так же, как и на конференции). А нетворк - это моя забота. Если я хочу работать в этом месте, то для меня важны люди и контакт с ними, важно выстраивать эти связи. Это мне надо. Отношения, это вообще большая часть работы менеджера.
А раз так, то и на лазертаг меня зовите, и на картинг.
На первой работе я думал, вау, компания так балует сотрудников, кормит нас красной рыбкой на корпоративе. Затем оказалось, что в некоторых фирмах по пятницам пиво и пиццу! Это казалось уже каким-то социальным экспериментом.
На деле такие ивенты нужны в первую очередь самой компании. Они повышают лояльность и вовлеченность сотрудников. Народ больше дружит, эффективнее работает и реже увольняется. И это все за каких-то 100-200 баксов на человека в год!
Недавно я устраивал тимбилдинг для своего отдела. Через час я слышу, что половина людей говорит о работе. Уже под другим градусом откровенности, но все же.
По той же причине топ компании строят мега-крутые офисы. Идея в том, чтобы люди проводили в них как можно больше времени. Когда у тебя под рукой спортзал, ресторан и массаж, то из офиса как будто и незачем уезжать. Все есть в кампусе. Ну а если вдруг придет хорошая идея по работе, то ты как раз уже в подходящей обстановке.
В общем, компания вкладывается в плюшки, чтобы ты поработал лишние 30 минут. Или познакомился с коллегой получше и стал более эффективным. Для кого-то это справедливая сделка, просто надо понимать, что если ты не платишь за товар (красную рыбку на корпоративе), то ты и есть товар.
Некоторые ребята, считают ее не такой справедливой и рассуждают так. Раз тимбилдинг, это рабочий ивент, то давайте проводить его в рабочее время. Но тут уже у компании юнит-экономика не сходится.
Я смотрю на тимбилдинги, как на возможность понетворкать (так же, как и на конференции). А нетворк - это моя забота. Если я хочу работать в этом месте, то для меня важны люди и контакт с ними, важно выстраивать эти связи. Это мне надо. Отношения, это вообще большая часть работы менеджера.
А раз так, то и на лазертаг меня зовите, и на картинг.
Хорошие и плохие формулировки для увольнения
Увольнение - супер стрессовый момент. Переживать его болезненно, порой люди месяцами приходят в себя.
Сотруднику, конечно, в сто раз хуже, но и для менеджера это сложная ситуация. Просто произнести “ты уволен” пипец как тяжело. Слова здесь играют максимально важную роль и напортачить здесь легко.
Вот несколько формулировок, которые мне кажутся приемлимыми:
Нормально:
- Мы решили завершить с тобой рабочие отношения.
- Мы решили расторгнуть наш рабочий договор.
- Мы останавливаем наше сотрудничество.
- Мы больше не можем работать вместе.
Ну так:
- Мы решили попрощаться с тобой.
- У нас нет возможности продолжить наше сотрудничество (лукавство, потому что если нету возможности, то это сокращение, а не увольнение).
Плохо:
- Ты уволен (жестковато)
- Мы больше не нуждаемся в твоих услугах (я вам что, гараж сдаю? каких услугах?)
- Тебе / нам пора двигаться дальше (а раньше мы на месте стояли? куда двигаться?)
- Мы решили отпустить тебя (а раньше я что, привязан был?)
Дальше в разговоре надо обязательно объяснить, почему так произошло, с чем именно человек не справился, что вы советуете ему исправить в будущем. Еще хорошо показать, как вы - его менеджер - пытались помочь, но не получилось. Но это вы и без меня знаете.
Какие еще есть популярные формулировки? Напишите в комментарии 👇
Увольнение - супер стрессовый момент. Переживать его болезненно, порой люди месяцами приходят в себя.
Сотруднику, конечно, в сто раз хуже, но и для менеджера это сложная ситуация. Просто произнести “ты уволен” пипец как тяжело. Слова здесь играют максимально важную роль и напортачить здесь легко.
Вот несколько формулировок, которые мне кажутся приемлимыми:
Нормально:
- Мы решили завершить с тобой рабочие отношения.
- Мы решили расторгнуть наш рабочий договор.
- Мы останавливаем наше сотрудничество.
- Мы больше не можем работать вместе.
Ну так:
- Мы решили попрощаться с тобой.
- У нас нет возможности продолжить наше сотрудничество (лукавство, потому что если нету возможности, то это сокращение, а не увольнение).
Плохо:
- Ты уволен (жестковато)
- Мы больше не нуждаемся в твоих услугах (я вам что, гараж сдаю? каких услугах?)
- Тебе / нам пора двигаться дальше (а раньше мы на месте стояли? куда двигаться?)
- Мы решили отпустить тебя (а раньше я что, привязан был?)
Дальше в разговоре надо обязательно объяснить, почему так произошло, с чем именно человек не справился, что вы советуете ему исправить в будущем. Еще хорошо показать, как вы - его менеджер - пытались помочь, но не получилось. Но это вы и без меня знаете.
Какие еще есть популярные формулировки? Напишите в комментарии 👇
Процессы vs их отсутствие
С процессами жить в кайф. Понятно что и как работать, пользуешься готовыми гайдлайнами и шаблонами, не тратишь время на поиск нужных инструментов.
Проблема процессов в том, что их поддержка стоит денег. Надо постоянно что-то писать на вики, рисовать схемы, договариваться с другими отделами, следить, чтобы процессы не протухли, платить за лицензии, в конце концов.
Без процессов жить тоже круто - делаешь так, как имеет смысл в моменте.
Инцидент на проде? Починили и забыли, postmortem пройдет в голове программиста автоматически сразу после деплоя. Выкинули из спринта половину задач, чтобы помочь сейлам закрыть сделку? Супер, денежки на счету важнее красивого берндаун чарта.
Пока ситуация позволяет жить без процесса - не усложняй себе жизнь. Чем меньше у тебя процессов, тем больше времени остается на реальную работу.
В какой-то момент ты заметишь, что жить без процесса стало дорого. Например, твое приложение выросло и ошибки в проде стали заметно влиять на выручку. Значит, пришло время прикручивать логирование, мониторинг и вводить postmortem.
Можно прикрутить все это с 1 дня, супер быстро фиксить баги и иметь довольного тимлида. Но какой в этом смысл, если где-то плачет продакт, не нашедший маркет фит?
С процессами жить в кайф. Понятно что и как работать, пользуешься готовыми гайдлайнами и шаблонами, не тратишь время на поиск нужных инструментов.
Проблема процессов в том, что их поддержка стоит денег. Надо постоянно что-то писать на вики, рисовать схемы, договариваться с другими отделами, следить, чтобы процессы не протухли, платить за лицензии, в конце концов.
Без процессов жить тоже круто - делаешь так, как имеет смысл в моменте.
Инцидент на проде? Починили и забыли, postmortem пройдет в голове программиста автоматически сразу после деплоя. Выкинули из спринта половину задач, чтобы помочь сейлам закрыть сделку? Супер, денежки на счету важнее красивого берндаун чарта.
Пока ситуация позволяет жить без процесса - не усложняй себе жизнь. Чем меньше у тебя процессов, тем больше времени остается на реальную работу.
В какой-то момент ты заметишь, что жить без процесса стало дорого. Например, твое приложение выросло и ошибки в проде стали заметно влиять на выручку. Значит, пришло время прикручивать логирование, мониторинг и вводить postmortem.
Можно прикрутить все это с 1 дня, супер быстро фиксить баги и иметь довольного тимлида. Но какой в этом смысл, если где-то плачет продакт, не нашедший маркет фит?
Какое письмо прочитают
В этом году я вел пару проектов, в которых участвовало много команд. Самый большой затрагивал 33 команды, вместе с которыми мы раскатывали обновление реакта на фронте.
Когда координируешь такое количество зависимостей, коммуникация играет критическую роль. Чтобы люди поняли и сделали то, о чем ты их просишь, нужно сформулировать задачу максимально понятно.
Самое базовое, что надо упомянуть это:
- в чем суть задачи (гайдлайны, примеры, сколько примерно займет);
- почему мы это делаем;
- какие команды участвуют;
- какие сроки.
С этой инфой другие менеджеры уже могут что-то планировать.
Экспериментируя с форматом, я заметил, что влияет не только ЧТО ты пишешь, но и КАК. Ниже несколько таких экспериментов и как они влияют на реакцию:
📧Отправить письмо на [email protected] - 10 очков
📧Отправить письмо только на тех, кто участвует в проекте - 20
📧Отправить письмо утром - 10 (вечером = минус 10)
📧Перечислить команды \ тимлидов, от кого именно нужна помощь - 40
📧Упомянуть потенциальную прибыли от проекта (в деньгах) - 30
📧Поставить в копию менеджеров тех людей, от кого нужна помощь - 50
📧Поставить в копию СТО - 100
📧Написать то же самое каждому в личку - 70
📧Написать то же самое в публичный слак канал каждой команды - 100
📧Написать то же самое в джира тикете и перевести на менеджера - 30
Какие приемы у вас работают?
В этом году я вел пару проектов, в которых участвовало много команд. Самый большой затрагивал 33 команды, вместе с которыми мы раскатывали обновление реакта на фронте.
Когда координируешь такое количество зависимостей, коммуникация играет критическую роль. Чтобы люди поняли и сделали то, о чем ты их просишь, нужно сформулировать задачу максимально понятно.
Самое базовое, что надо упомянуть это:
- в чем суть задачи (гайдлайны, примеры, сколько примерно займет);
- почему мы это делаем;
- какие команды участвуют;
- какие сроки.
С этой инфой другие менеджеры уже могут что-то планировать.
Экспериментируя с форматом, я заметил, что влияет не только ЧТО ты пишешь, но и КАК. Ниже несколько таких экспериментов и как они влияют на реакцию:
📧Отправить письмо на [email protected] - 10 очков
📧Отправить письмо только на тех, кто участвует в проекте - 20
📧Отправить письмо утром - 10 (вечером = минус 10)
📧Перечислить команды \ тимлидов, от кого именно нужна помощь - 40
📧Упомянуть потенциальную прибыли от проекта (в деньгах) - 30
📧Поставить в копию менеджеров тех людей, от кого нужна помощь - 50
📧Поставить в копию СТО - 100
📧Написать то же самое каждому в личку - 70
📧Написать то же самое в публичный слак канал каждой команды - 100
📧Написать то же самое в джира тикете и перевести на менеджера - 30
Какие приемы у вас работают?
Как запускать большие проекты с зависимостями от других команд - Dependency mapping
Представьте, что разрабатываете фичу по отправке картинок в чат. Чтобы ее сделать, картинки нужно сохранить на сервер. За хранение всех данных в апе отвечает отдельная команда - data storage squad. Как убедить их взять нашу фичу в работу?
Можно вытащить их продакта на звонок, рассказать, какая это крутая фича, сколько она принесет денег компании и славы продакту, если взять ее уже в следующий спринт.
Правда у data storage squad есть свой роудмап со своими дедлайнами и стейкхолдерами. Даже если они вдохновятся нашей идеей, не факт, что они смогут тут же ее приоритезировать. Скорее всего, ответ будет “давайте через 2 квартала”.
Следующий шаг - эскалировать в своего менеджера или СТО. Если у нас нету полномочий ставить людей на проекты, то нужно найти того, у кого они есть, чтобы разобраться с зависимостью и запланировать проект.
В небольшой компании, где новые проекты стартуют нечасто, это вполне рабочий вариант. Обычно здесь 1 команда отвечает за 1 продукт. Поэтому и зависимостей не так много, СТО вполне может управлять этим вручную.
В большой компании новые проекты стартуют постоянно и над 1 продуктом работает сразу 5-10-20 команд. Зависимостей тут дофига и решать их по мере возникновения тяжело, нужен какой-то процесс. Обычно он является частью планирования, и повторяется раз в квартал или год. Называется dependency mapping и выглядит так:
👉 продакт пишет документ, описывающий проект;
👉 все команды собираются на воркшоп, где представляют свои проекты и обмениваются зависимостями;
👉 все принимают или отклоняют зависимости других;
👉 принятые зависимости идут в беклоги команд, по ним можно планировать разработку;
В первом посте в комментариях я более подробно опишу этот процесс.
По большому счету, на dependency mapping происходит все то же самое, что и на первом шаге, когда мы ходили к продакту. Только тут все команды делают это одновременно.
Плюс такого процесса в том, что не надо ждать, пока закончится какой-то эксперимент или там VP вернется из отпуска, чтобы принять решение. Есть четкий дедлайн за 2 недели дать ответ по всем зависимостям. Поэтому все фокусируются на этом планировании, быстро друг с другом договариваются и бегут вместе делать большие проекты.
Представьте, что разрабатываете фичу по отправке картинок в чат. Чтобы ее сделать, картинки нужно сохранить на сервер. За хранение всех данных в апе отвечает отдельная команда - data storage squad. Как убедить их взять нашу фичу в работу?
Можно вытащить их продакта на звонок, рассказать, какая это крутая фича, сколько она принесет денег компании и славы продакту, если взять ее уже в следующий спринт.
Правда у data storage squad есть свой роудмап со своими дедлайнами и стейкхолдерами. Даже если они вдохновятся нашей идеей, не факт, что они смогут тут же ее приоритезировать. Скорее всего, ответ будет “давайте через 2 квартала”.
Следующий шаг - эскалировать в своего менеджера или СТО. Если у нас нету полномочий ставить людей на проекты, то нужно найти того, у кого они есть, чтобы разобраться с зависимостью и запланировать проект.
В небольшой компании, где новые проекты стартуют нечасто, это вполне рабочий вариант. Обычно здесь 1 команда отвечает за 1 продукт. Поэтому и зависимостей не так много, СТО вполне может управлять этим вручную.
В большой компании новые проекты стартуют постоянно и над 1 продуктом работает сразу 5-10-20 команд. Зависимостей тут дофига и решать их по мере возникновения тяжело, нужен какой-то процесс. Обычно он является частью планирования, и повторяется раз в квартал или год. Называется dependency mapping и выглядит так:
👉 продакт пишет документ, описывающий проект;
👉 все команды собираются на воркшоп, где представляют свои проекты и обмениваются зависимостями;
👉 все принимают или отклоняют зависимости других;
👉 принятые зависимости идут в беклоги команд, по ним можно планировать разработку;
В первом посте в комментариях я более подробно опишу этот процесс.
По большому счету, на dependency mapping происходит все то же самое, что и на первом шаге, когда мы ходили к продакту. Только тут все команды делают это одновременно.
Плюс такого процесса в том, что не надо ждать, пока закончится какой-то эксперимент или там VP вернется из отпуска, чтобы принять решение. Есть четкий дедлайн за 2 недели дать ответ по всем зависимостям. Поэтому все фокусируются на этом планировании, быстро друг с другом договариваются и бегут вместе делать большие проекты.
Уходить с бесполезных встреч
Чтобы митинг прошел хорошо, нужна подготовка - позвать правильных людей, обозначать агенду, высылать заранее материалы.
Но как ни готовься, иногда встреча все равно заходит куда-то не туда. Например, застревают на одном вопросе, уходят в сторону или просто позвали кучу народу в формате «сходи, послушай». Сидеть на таких - мука и путь к выгоранию.
Высшим классом в такой ситуации считается сказать «коллеги, вижу, что я не добавляю ценности этому разговору» и выйти.
Чтобы так сказать, нужны смелость и определенная культура в компании. Где-то могут увидеть в таком поступке неуважение и даже грубость. Это же все равно, что развернуть большой плакат с надписью «встреча - кошмар, организатор - балбес». Хотя наша цель лишь тратить время с умом.
Если вы руководитель и хотите, чтобы такая культура пробивалась в команде, вам нужно самому пару раз так уйти с митов. И народ подхватит.
Тыщу раз слышал эту фразу «не стесняйтесь уходить, если встреча бесполезна для вас”. Но реально это работало, только когда люди видели, что менеджеры сами делают то, что советуют другим (<-совет на века).
На прошлой неделе как раз был свидетелем такой ситуации. Минут через 10 после начала тимлид сказал «знаете, вопрос ко мне почти не относится, я пожалуй пойду. Напишите потом, если будет что-то для меня». И ничего, никто не умер, даже наоборот, оставшиеся немного оживились и разговор пошел быстрее.
Чтобы митинг прошел хорошо, нужна подготовка - позвать правильных людей, обозначать агенду, высылать заранее материалы.
Но как ни готовься, иногда встреча все равно заходит куда-то не туда. Например, застревают на одном вопросе, уходят в сторону или просто позвали кучу народу в формате «сходи, послушай». Сидеть на таких - мука и путь к выгоранию.
Высшим классом в такой ситуации считается сказать «коллеги, вижу, что я не добавляю ценности этому разговору» и выйти.
Чтобы так сказать, нужны смелость и определенная культура в компании. Где-то могут увидеть в таком поступке неуважение и даже грубость. Это же все равно, что развернуть большой плакат с надписью «встреча - кошмар, организатор - балбес». Хотя наша цель лишь тратить время с умом.
Если вы руководитель и хотите, чтобы такая культура пробивалась в команде, вам нужно самому пару раз так уйти с митов. И народ подхватит.
Тыщу раз слышал эту фразу «не стесняйтесь уходить, если встреча бесполезна для вас”. Но реально это работало, только когда люди видели, что менеджеры сами делают то, что советуют другим (<-совет на века).
На прошлой неделе как раз был свидетелем такой ситуации. Минут через 10 после начала тимлид сказал «знаете, вопрос ко мне почти не относится, я пожалуй пойду. Напишите потом, если будет что-то для меня». И ничего, никто не умер, даже наоборот, оставшиеся немного оживились и разговор пошел быстрее.