Как давать негативный фидбек
Одно из самых сложных в работе для меня - давать негативный фидбек.
С позитивным все легко и просто, ведь хвалить людей всегда приятно. А критиковать как-то неуютно, таких разговоров хочется избежать. Мол, откуда вообще у меня право говорить человеку как ему жить?
Обычно фидбек дают на встречах 1-1. Чтобы сотрудник прислушался, надо доносить проблему максимально точно: ты не вложился в оценку -> поехали сроки -> заказчик недоволен. Если говорить общими фразами и полунамеками, есть большой шанс, что тебя не услышат.
С другой стороны, важно не задеть чувства человека. Чтобы ему не показалось, что его отчитывают как школьника за невыполненную домашку 🤓.
Есть разные техники, которые помогают справиться с этим балансом, например, бутерброд или BOFF.
Мне понравились принципы, которые использует Нетфликс, потому что они короткие и простые. Всего 2 совета для тех, кто дает фидбек и 2 для принимающей стороны:
1. Стремись помочь. Критикуй с искренним желанием сделать мир лучше.
2. Предлагай конкретные шаги. Объясняй, что именно человек сделал не так, какой был негативный эффект и как его можно было избежать.
3. Будь благодарен за обратную связь. Когда слышишь негатив, твоя естественная реакция - начать оправдываться и защищаться. Ее надо побороть и вспомнить про пункт 1.
4. Не всем советам обязательно следовать. Некоторые из них могу быть действительно "мимо". Только тебе решать к каким прислушаться.
Одно из самых сложных в работе для меня - давать негативный фидбек.
С позитивным все легко и просто, ведь хвалить людей всегда приятно. А критиковать как-то неуютно, таких разговоров хочется избежать. Мол, откуда вообще у меня право говорить человеку как ему жить?
Обычно фидбек дают на встречах 1-1. Чтобы сотрудник прислушался, надо доносить проблему максимально точно: ты не вложился в оценку -> поехали сроки -> заказчик недоволен. Если говорить общими фразами и полунамеками, есть большой шанс, что тебя не услышат.
С другой стороны, важно не задеть чувства человека. Чтобы ему не показалось, что его отчитывают как школьника за невыполненную домашку 🤓.
Есть разные техники, которые помогают справиться с этим балансом, например, бутерброд или BOFF.
Мне понравились принципы, которые использует Нетфликс, потому что они короткие и простые. Всего 2 совета для тех, кто дает фидбек и 2 для принимающей стороны:
1. Стремись помочь. Критикуй с искренним желанием сделать мир лучше.
2. Предлагай конкретные шаги. Объясняй, что именно человек сделал не так, какой был негативный эффект и как его можно было избежать.
3. Будь благодарен за обратную связь. Когда слышишь негатив, твоя естественная реакция - начать оправдываться и защищаться. Ее надо побороть и вспомнить про пункт 1.
4. Не всем советам обязательно следовать. Некоторые из них могу быть действительно "мимо". Только тебе решать к каким прислушаться.
Как следить за качеством (чек-лист)
Представьте, что приходите на новый проект и начинаете его изучать. Что досталось вам в наследство?
Можно пойти по классическому пути и исследовать проектный треугольник. Довольно просто вы узнаете, как обстоят дела со сроками, бюджетом и стоимостью. Для этого достаточно поговорить с прошлым менеджером или тимлидом.
Но как понять, что с качеством? Простого ответа тут не будет, потому что качество нельзя измерить одной цифрой и сказать вот тут низкое, а тут высокое. Вместо этого можно поисследовать разные кусочки проекта, которые в итоге на него влияют.
Таких кусочков много, хватило на целый чек-лист:
https://telegra.ph/CHek-list-kachestva-proekta-03-29
Представьте, что приходите на новый проект и начинаете его изучать. Что досталось вам в наследство?
Можно пойти по классическому пути и исследовать проектный треугольник. Довольно просто вы узнаете, как обстоят дела со сроками, бюджетом и стоимостью. Для этого достаточно поговорить с прошлым менеджером или тимлидом.
Но как понять, что с качеством? Простого ответа тут не будет, потому что качество нельзя измерить одной цифрой и сказать вот тут низкое, а тут высокое. Вместо этого можно поисследовать разные кусочки проекта, которые в итоге на него влияют.
Таких кусочков много, хватило на целый чек-лист:
https://telegra.ph/CHek-list-kachestva-proekta-03-29
Кик офф
Когда стартуешь новый проект, всем нужен какой-то условный знак, мол, "начинаем". Для этого придумали кик офф встречу. В переводе с футбольного, это буквально ввод мяча с центра поля, значение слова сохранилось и в ИТ.
Кик офф проводит менеджер, приглашая заказчика, его команду, свою команду и сейла, который заключил договор.
Вот что надо обсудить:
1️⃣ Попросить заказчика еще раз проговорить цель проекта и свои ожидания. Тут нам и нужен сейл, чтобы все показания сошлись (скоуп, дедлайны).
2️⃣ Представить команду. Рассказать кто за что отвечает.
3️⃣ Рассказать о процессе разработки.
4️⃣ Рассказать о роли заказчика в этом процессе, что от него ожидается. Обычно это аппрув требований и участие в демо. Сразу договариваемся о времени созвонов и высылаем на них инвайты.
5️⃣ Спросить, кто будет бекапить закачика, если он недоступен, определить полномочия этого человека. Заказчики люди занятые, любят пропадать.
6️⃣ Рассказать о планах первой итерации, т.е. что мы сделаем за 1 спринт.
7️⃣ Рассказать о первой поставке, когда ожидается и что в нее войдет.
8️⃣ Организационные штучки: таймзона, время доступности, каналы связи, отчеты, доступ в джиру, вот это все.
А дальше идем делать классный проект 😎.
Когда стартуешь новый проект, всем нужен какой-то условный знак, мол, "начинаем". Для этого придумали кик офф встречу. В переводе с футбольного, это буквально ввод мяча с центра поля, значение слова сохранилось и в ИТ.
Кик офф проводит менеджер, приглашая заказчика, его команду, свою команду и сейла, который заключил договор.
Вот что надо обсудить:
1️⃣ Попросить заказчика еще раз проговорить цель проекта и свои ожидания. Тут нам и нужен сейл, чтобы все показания сошлись (скоуп, дедлайны).
2️⃣ Представить команду. Рассказать кто за что отвечает.
3️⃣ Рассказать о процессе разработки.
4️⃣ Рассказать о роли заказчика в этом процессе, что от него ожидается. Обычно это аппрув требований и участие в демо. Сразу договариваемся о времени созвонов и высылаем на них инвайты.
5️⃣ Спросить, кто будет бекапить закачика, если он недоступен, определить полномочия этого человека. Заказчики люди занятые, любят пропадать.
6️⃣ Рассказать о планах первой итерации, т.е. что мы сделаем за 1 спринт.
7️⃣ Рассказать о первой поставке, когда ожидается и что в нее войдет.
8️⃣ Организационные штучки: таймзона, время доступности, каналы связи, отчеты, доступ в джиру, вот это все.
А дальше идем делать классный проект 😎.
Удобные письма
Некоторые письма только откроешь и сразу хочется закрыть. "Ой, тут что-то непонятное, разберусь с этим потом". И откладываешь в долгий ящик.
Такое письмо легко вычислить. Если текста больше, чем на лист А4, в нем есть эмоции или после прочтения хочется сказать "зачем я это прочитал?", значит, что-то не так.
Чтобы на ваши письма отвечали быстро, старайтесь экономить время читателя и предугадывать его вопросы по ходу текста. Например, используя вот такую структуру:
- Проблема
- Возможное решение (1)
- Оптимальное решение (2)
- Что будет, если забить
- Когда надо принять решение
Человек, который получит такое письмо, сможет ответить на него всего одним символом - "1". Одна цифра и вопрос решен, класс же! При этом читатель потратил минимум своего времени, и будет вам за это благодарен.
Некоторые письма только откроешь и сразу хочется закрыть. "Ой, тут что-то непонятное, разберусь с этим потом". И откладываешь в долгий ящик.
Такое письмо легко вычислить. Если текста больше, чем на лист А4, в нем есть эмоции или после прочтения хочется сказать "зачем я это прочитал?", значит, что-то не так.
Чтобы на ваши письма отвечали быстро, старайтесь экономить время читателя и предугадывать его вопросы по ходу текста. Например, используя вот такую структуру:
- Проблема
- Возможное решение (1)
- Оптимальное решение (2)
- Что будет, если забить
- Когда надо принять решение
Человек, который получит такое письмо, сможет ответить на него всего одним символом - "1". Одна цифра и вопрос решен, класс же! При этом читатель потратил минимум своего времени, и будет вам за это благодарен.
Планирование релизов
У зрелых команд есть релиз планирование. Его делают, чтобы определить какие фичи когда выпускать. Эта инфа нужна как сейлам, чтобы давать обещания клиентам, так и команде, чтобы правильно организовать разработку.
Проходит оно так. Собираются бизнес и технари вместе и разговаривают:
1. Бизнес объясняет что надо поставить, чтобы ему было хорошо (= выпуск каких фич принесет максимальную пользу).
2. Технари объясняют какие задачи им удобнее (проще, легче, дешевле) поставить в ближайшее время.
На основе 1 и 2 договариваются о план релиза. Его записывают в джиру или ноушен, чтобы все были в курсе. Вот и все релиз планирование 😀
Хорошие практики:
1️⃣ Планировать на несколько релизов вперед, оптимально на 1-2 месяца. Если закладывать больше - план будет неточным и постоянно меняться. Меньше - сложно продавать. Здесь речь именно о точном плане с конкретными датами. Примерный план у нас уже есть - это роудмап.
2️⃣ Постепенные релизы больших, рисковых изменений. Выкатываем новый код последовательно, начиная с небольшой части пользователей. Если у них все хорошо - раскатываем на остальных. А если плохо, то пострадают хотя бы не все.
3️⃣ Релизить часто, но мало. При таком подходе сразу видно в каком месте проблема, ее легче локализовать, а следовательно, и починить. Ну и откатывать маленькие релизы проще.
На фото: великолепная фича Releases в джире
У зрелых команд есть релиз планирование. Его делают, чтобы определить какие фичи когда выпускать. Эта инфа нужна как сейлам, чтобы давать обещания клиентам, так и команде, чтобы правильно организовать разработку.
Проходит оно так. Собираются бизнес и технари вместе и разговаривают:
1. Бизнес объясняет что надо поставить, чтобы ему было хорошо (= выпуск каких фич принесет максимальную пользу).
2. Технари объясняют какие задачи им удобнее (проще, легче, дешевле) поставить в ближайшее время.
На основе 1 и 2 договариваются о план релиза. Его записывают в джиру или ноушен, чтобы все были в курсе. Вот и все релиз планирование 😀
Хорошие практики:
1️⃣ Планировать на несколько релизов вперед, оптимально на 1-2 месяца. Если закладывать больше - план будет неточным и постоянно меняться. Меньше - сложно продавать. Здесь речь именно о точном плане с конкретными датами. Примерный план у нас уже есть - это роудмап.
2️⃣ Постепенные релизы больших, рисковых изменений. Выкатываем новый код последовательно, начиная с небольшой части пользователей. Если у них все хорошо - раскатываем на остальных. А если плохо, то пострадают хотя бы не все.
3️⃣ Релизить часто, но мало. При таком подходе сразу видно в каком месте проблема, ее легче локализовать, а следовательно, и починить. Ну и откатывать маленькие релизы проще.
На фото: великолепная фича Releases в джире
Как не надо увольняться
В моей команде работал рубист Костя. Он был крепким мидлом, умел писать хороший код. Костя был скромным парнем, не ленился, но и в бой особо не рвался. Он спокойно делал свои таски и в 6 вечера шел домой. Меня устраивала работа с ним, такие руки всегда нужны на проекте.
Мы проводили встречи 1-1 каждые пару месяцев, чтобы обсудить как идут дела, дать друг другу фидбек. На одной такой встрече все шло как обычно: "Особых проблем на проекте не вижу, с командой комфортно" и т.д. и т.п.
Встреча уже подходила к концу, я подводил итог, что мы за сегодня обсудили и скорее в шутку сказал: "Все в порядке, работаем дальше, увольняться пока не собираешься". Костя заулыбался и говорит "Ну, вообще-то, собираюсь".
Тут я охренел. Мы только что проговорили полчаса о всяких мелочах, и ты даже не упомянул, что хочешь уйти?? 🤨
Оказалось, что он уже нашел новую работу в каком-то беттинг-стартапе и договорился выйти к ним через 2 недели. 2 недели! Наш тогдашний беклог трещал от we-need-to-build-it-asap-фич, а на поиски толкового рубиста на рынке уходили месяцы. Для проекта это была большая проблема.
После долгих переговор мы договорились, что Костя отработает 3 недели, и еще 2 будет помогать на парт-тайме пару часов в день.
Не увольняйтесь как Костя. Это больно для команд, менеджеров и клиентов.
Ради приличия и душевного спокойствия Кости, имя тут ненастоящее :) Эта история смерджена из 2х реальных историй, которые когда-то произошли со мной.
В моей команде работал рубист Костя. Он был крепким мидлом, умел писать хороший код. Костя был скромным парнем, не ленился, но и в бой особо не рвался. Он спокойно делал свои таски и в 6 вечера шел домой. Меня устраивала работа с ним, такие руки всегда нужны на проекте.
Мы проводили встречи 1-1 каждые пару месяцев, чтобы обсудить как идут дела, дать друг другу фидбек. На одной такой встрече все шло как обычно: "Особых проблем на проекте не вижу, с командой комфортно" и т.д. и т.п.
Встреча уже подходила к концу, я подводил итог, что мы за сегодня обсудили и скорее в шутку сказал: "Все в порядке, работаем дальше, увольняться пока не собираешься". Костя заулыбался и говорит "Ну, вообще-то, собираюсь".
Тут я охренел. Мы только что проговорили полчаса о всяких мелочах, и ты даже не упомянул, что хочешь уйти?? 🤨
Оказалось, что он уже нашел новую работу в каком-то беттинг-стартапе и договорился выйти к ним через 2 недели. 2 недели! Наш тогдашний беклог трещал от we-need-to-build-it-asap-фич, а на поиски толкового рубиста на рынке уходили месяцы. Для проекта это была большая проблема.
После долгих переговор мы договорились, что Костя отработает 3 недели, и еще 2 будет помогать на парт-тайме пару часов в день.
Не увольняйтесь как Костя. Это больно для команд, менеджеров и клиентов.
Ради приличия и душевного спокойствия Кости, имя тут ненастоящее :) Эта история смерджена из 2х реальных историй, которые когда-то произошли со мной.
Записал небольшой вебинар про коммуникацию для менеджеров в iampm.club. Рассказываю
- как общаться с заказчиком, чтобы он тебя зауважал;
- какими словами можно задеть американца;
- что делать, чтобы стать любимчиком босса;
Посмотрите, тут интересно:
https://youtu.be/BrBf96RNn6s?t=120
- как общаться с заказчиком, чтобы он тебя зауважал;
- какими словами можно задеть американца;
- что делать, чтобы стать любимчиком босса;
Посмотрите, тут интересно:
https://youtu.be/BrBf96RNn6s?t=120
YouTube
Бонусная лекция: "Как общаться с заказчиком и не наломать дров" 3
Работа менеджера - давать контекст
Программисты пишут код, тестировщики его проверяют, дизайнеры рисуют интерфейсы, а что полезного делают менеджеры? Дают контекст.
Цель нашей работы - дать как можно больше информации о проекте, чтобы другие приняли правильное решение.
Например, можно рассказывать разработчикам как устроен бизнес. Как платят клиенты, что их больше всего интересует, какая у компании ближайшая цель. Благодаря этим знаниям программисту будет очевидно, что вот на это письмо клиента надо очень быстро ответить, а вот тот баг может подождать. И он в моменте примет оптимальное решение.
Или в обратную сторону - рассказывать бизнесу про разработку. Какие у нас сейчас проблемы, на что они влияют, какие фичи будет сделать очень сложно, а какие щелкнем как орешки. Благодаря этим знаниям бизнес сможет давать более точные обещания клиентам и выглядеть экспертно.
Менеджер - это такой мостик между разработкой и бизнесом, задача которого сблизить и подружить эти две вселенные.
Программисты пишут код, тестировщики его проверяют, дизайнеры рисуют интерфейсы, а что полезного делают менеджеры? Дают контекст.
Цель нашей работы - дать как можно больше информации о проекте, чтобы другие приняли правильное решение.
Например, можно рассказывать разработчикам как устроен бизнес. Как платят клиенты, что их больше всего интересует, какая у компании ближайшая цель. Благодаря этим знаниям программисту будет очевидно, что вот на это письмо клиента надо очень быстро ответить, а вот тот баг может подождать. И он в моменте примет оптимальное решение.
Или в обратную сторону - рассказывать бизнесу про разработку. Какие у нас сейчас проблемы, на что они влияют, какие фичи будет сделать очень сложно, а какие щелкнем как орешки. Благодаря этим знаниям бизнес сможет давать более точные обещания клиентам и выглядеть экспертно.
Менеджер - это такой мостик между разработкой и бизнесом, задача которого сблизить и подружить эти две вселенные.
UX долги
Все знают про технический долг, попривыкли к этому понятию. Если бизнес занимает у разработки немного качества, чтобы сделать фичу супер быстро, то надо сразу планировать доработки и не тянуть с возвратом долга. В противном случае проекту плохеет: новые фичи занимают все больше времени, постоянные баги в продакшене, лица программистов становятся грустнее с каждым релизом 😔.
А бывает еще UX долг. Это аналогичная штука, только про интерфейс. Например, мы делаем экран транзакций в мобильном банке и решаем отложить вот эти задачи, чтобы поскорее выпустить фичу:
1️⃣ обработать состояние, если еще не было транзакций;
2️⃣ запомнить последнюю выбранную дату в сортировке;
3️⃣ разные стили в списке транзакций у юр. лиц и физ. лиц;
Действительно, без них можно жить какое-то время и даже пользоваться приложением. Но в 2021 люди привыкли к вылизанным интерфейсам в духе эппл мьюзик и яндекс такси. Поэтому, когда они видят эти недоработки, в голове возникает вопрос "может надо было счет в тинькове открывать?". А мы, понятно, не хотим, чтобы они так думали, а любили только наш банк.
С UX долгом такие же правила, как и с техническим. Его надо:
📌 легализовать - объяснить бизнесу, почему он возникает и что будет, если на него забить.
📌 отдавать - в каждом спринте планировать немного времени на UX долг. Я обычно беру где-то 5%, т.е. 1-2 небольшие задачи.
Все знают про технический долг, попривыкли к этому понятию. Если бизнес занимает у разработки немного качества, чтобы сделать фичу супер быстро, то надо сразу планировать доработки и не тянуть с возвратом долга. В противном случае проекту плохеет: новые фичи занимают все больше времени, постоянные баги в продакшене, лица программистов становятся грустнее с каждым релизом 😔.
А бывает еще UX долг. Это аналогичная штука, только про интерфейс. Например, мы делаем экран транзакций в мобильном банке и решаем отложить вот эти задачи, чтобы поскорее выпустить фичу:
1️⃣ обработать состояние, если еще не было транзакций;
2️⃣ запомнить последнюю выбранную дату в сортировке;
3️⃣ разные стили в списке транзакций у юр. лиц и физ. лиц;
Действительно, без них можно жить какое-то время и даже пользоваться приложением. Но в 2021 люди привыкли к вылизанным интерфейсам в духе эппл мьюзик и яндекс такси. Поэтому, когда они видят эти недоработки, в голове возникает вопрос "может надо было счет в тинькове открывать?". А мы, понятно, не хотим, чтобы они так думали, а любили только наш банк.
С UX долгом такие же правила, как и с техническим. Его надо:
📌 легализовать - объяснить бизнесу, почему он возникает и что будет, если на него забить.
📌 отдавать - в каждом спринте планировать немного времени на UX долг. Я обычно беру где-то 5%, т.е. 1-2 небольшие задачи.
Грубая оценка
[Заказчик]: - хочу вот такую фичу
[Менеджер]: - ок, мы оценим и завтра пришлем сколько будет стоить
[З]: - да, ок, а скажи хотя бы примерно сколько? какой порядок цифр?
[Тимлид, пишет в личку]: - по разработке там работы +- на неделю
[М]: - 100 часов, или $4,000, если грубо
--------------------------------
Иногда нам нужно что-то быстро оценить. В этом случае можно воспользоваться вот такой формулой:
общая оценка = оценка на разработку * 2,5
То есть, если на девелопмент нужно 40 часов, то вся фича целиком, от требований до поставки, будет стоить заказчику 40*2,5 = 100 часов. Дальше умножаем на средний рейт и получаем стоимость.
Конечно, цифры примерные и на каждом проекте коэффициент будет разный. В банковском софте больше легаси и долгое тестирование, а в играх надо рисовать персонажей и уровни, там больше дизайна. В среднем цифра будет от 2,2 до 3.
И вот откуда она берется:
[Заказчик]: - хочу вот такую фичу
[Менеджер]: - ок, мы оценим и завтра пришлем сколько будет стоить
[З]: - да, ок, а скажи хотя бы примерно сколько? какой порядок цифр?
[Тимлид, пишет в личку]: - по разработке там работы +- на неделю
[М]: - 100 часов, или $4,000, если грубо
--------------------------------
Иногда нам нужно что-то быстро оценить. В этом случае можно воспользоваться вот такой формулой:
общая оценка = оценка на разработку * 2,5
То есть, если на девелопмент нужно 40 часов, то вся фича целиком, от требований до поставки, будет стоить заказчику 40*2,5 = 100 часов. Дальше умножаем на средний рейт и получаем стоимость.
Конечно, цифры примерные и на каждом проекте коэффициент будет разный. В банковском софте больше легаси и долгое тестирование, а в играх надо рисовать персонажей и уровни, там больше дизайна. В среднем цифра будет от 2,2 до 3.
И вот откуда она берется:
Баланс экспертизы в команде
На своей первой работе я думал: "тут все молодые, неопытные (как и я), поэтому мы вечно не успеваем. Приду в место посерьезнее, там будут одни сеньоры, рутинно щелкающие проекты".
В месте посерьезнее ситуация стала лучше, но кардинально не изменилась. Джуны были и здесь! Зато теперь на каждом проекте есть главный программист, который шарит в кодовой базе и в каждом ее методе. Для него сложность этого проекта - в самый раз. Сложнее - уже не потянул бы; легче - заскучал.
Например, на проекте умный собачий ошейник было много трудных задач, которые на стэковерлоу не нагуглишь. Надо было разбираться в специальном протоколе mqtt, договариваться с фирмварщиками как часто синхронизировать данные, и думать как считать шаги у собаки (у них необычное количество ног 🐕). Поэтому в команде работали 4 сеньора, 5 мидлов и всего 1 джун.
А на другом проекте, а-ля клон вацапа, были понятные задачи, такие решались уже много раз. Смотри как сделано у конкурентов, да и делай так же. Поэтому там был 1 мидл и 1 джун, которых на полставки ревьювил сеньор.
Если взять среднюю температуру по больнице, то баланс экспертизы в команде выглядит так:
25% сеньоров, 50% мидлов, 25% джунов
Вот несколько причин почему он такой:
1️⃣ На любом проекте есть сложные задачи. Их отдают самым опытным разработчикам. Таких задач обычно немного, поэтому и сеньоров немного.
2️⃣ Больше всего задач с тэгом "обычные". Это продолжение уже существующего, хорошо знакомого команде функционала. Поэтому концентрация мидлов самая высокая.
3️⃣ На простых задачах (поправить юай, поменять текст в диалоговом окне и т.п.) можно сэкономить, если отдать джуниору. Для него это будет все еще интересная таска, а для ребята постарше уже скука. Вот такой вот коммунизм!
4️⃣ Более скиловый сетап часто невыгоден компании. Если будут работать одни сеньоры, она просто не выйдет в плюс. Поэтому команды "разбавляют" менее опытными специалистами.
На своей первой работе я думал: "тут все молодые, неопытные (как и я), поэтому мы вечно не успеваем. Приду в место посерьезнее, там будут одни сеньоры, рутинно щелкающие проекты".
В месте посерьезнее ситуация стала лучше, но кардинально не изменилась. Джуны были и здесь! Зато теперь на каждом проекте есть главный программист, который шарит в кодовой базе и в каждом ее методе. Для него сложность этого проекта - в самый раз. Сложнее - уже не потянул бы; легче - заскучал.
Например, на проекте умный собачий ошейник было много трудных задач, которые на стэковерлоу не нагуглишь. Надо было разбираться в специальном протоколе mqtt, договариваться с фирмварщиками как часто синхронизировать данные, и думать как считать шаги у собаки (у них необычное количество ног 🐕). Поэтому в команде работали 4 сеньора, 5 мидлов и всего 1 джун.
А на другом проекте, а-ля клон вацапа, были понятные задачи, такие решались уже много раз. Смотри как сделано у конкурентов, да и делай так же. Поэтому там был 1 мидл и 1 джун, которых на полставки ревьювил сеньор.
Если взять среднюю температуру по больнице, то баланс экспертизы в команде выглядит так:
25% сеньоров, 50% мидлов, 25% джунов
Вот несколько причин почему он такой:
1️⃣ На любом проекте есть сложные задачи. Их отдают самым опытным разработчикам. Таких задач обычно немного, поэтому и сеньоров немного.
2️⃣ Больше всего задач с тэгом "обычные". Это продолжение уже существующего, хорошо знакомого команде функционала. Поэтому концентрация мидлов самая высокая.
3️⃣ На простых задачах (поправить юай, поменять текст в диалоговом окне и т.п.) можно сэкономить, если отдать джуниору. Для него это будет все еще интересная таска, а для ребята постарше уже скука. Вот такой вот коммунизм!
4️⃣ Более скиловый сетап часто невыгоден компании. Если будут работать одни сеньоры, она просто не выйдет в плюс. Поэтому команды "разбавляют" менее опытными специалистами.
Выясни кто стейкхолдер
Был у меня один невероятно требовательный клиент - Сатиш. Он еще не подписал контракт, а уже задавал миллион вопросов, продавливал бесплатные изменения, жаловался как у нас все дорого и плохо работает.
По одной такой доработке переговоры зашли в тупик и под предлогом "сейчас придет мой босс и вас вообще размажет" к звонку присоединился Рави. Он был СЕО. Финальное решение подписывать с нами новый контракт или нет, было за ним.
К удивлению, мы быстро нашли общий язык и закрыли несколько принципиальных вопросов по скоупу, над которыми бились с Сатишем последние пару недель. Я смекнул, что оставшиеся вопросы тоже надо решать через СЕО, раз с ним легко договориться.
И действительно, за пару имейлов мы все уладили и подписали контракт. Сатиша я просто ставил в копию для приличия, а он предпочитал не высовываться.
-----------------------
В любых переговорах надо найти того, кто на самом деле принимает решение - стейкхолдера. Обычно это человек, который платит деньги, т.е. владеет бюджетом. Будет супер, если получится договариваться с ним напрямую. Если это невозможно, выясни какие у него интересы. То, что лоббируют его подчиненные, не факт что важно для него самого.
Был у меня один невероятно требовательный клиент - Сатиш. Он еще не подписал контракт, а уже задавал миллион вопросов, продавливал бесплатные изменения, жаловался как у нас все дорого и плохо работает.
По одной такой доработке переговоры зашли в тупик и под предлогом "сейчас придет мой босс и вас вообще размажет" к звонку присоединился Рави. Он был СЕО. Финальное решение подписывать с нами новый контракт или нет, было за ним.
К удивлению, мы быстро нашли общий язык и закрыли несколько принципиальных вопросов по скоупу, над которыми бились с Сатишем последние пару недель. Я смекнул, что оставшиеся вопросы тоже надо решать через СЕО, раз с ним легко договориться.
И действительно, за пару имейлов мы все уладили и подписали контракт. Сатиша я просто ставил в копию для приличия, а он предпочитал не высовываться.
-----------------------
В любых переговорах надо найти того, кто на самом деле принимает решение - стейкхолдера. Обычно это человек, который платит деньги, т.е. владеет бюджетом. Будет супер, если получится договариваться с ним напрямую. Если это невозможно, выясни какие у него интересы. То, что лоббируют его подчиненные, не факт что важно для него самого.
Инвестигейт на сложную фичу
Иногда в разработку приходит сложная фича. Например, рисовать на чужом экране при скриншаринге, как в Slack или Miro.
Если отдать такую на оценку команде, скорее всего, разброс цифр будет космическим, потому что непонятно как ее делать. Один программист даст 40 часов, а другой скажет минимум месяц. Можно, конечно, взять самую большую цифру и закомититься на нее, но даже так есть большой риск не успеть.
Опытный разработчик подскажет, что для сложной задачи нужен инвестигейт (исследование). Попросит полдня-день на изучение вопроса. За это время он почитает стэковерфлоу или документацию, попробует сделать самый сложный кусочек, чтобы понять какие дальше будут затыки, проконсультируется с опытными коллегами, словом, поищет решение.
Результатом такой задачи будет план разработки: дизайн (архитектура) фичи + разбивка на задачи. Конечно, никто не гарантирует закончить за 4-8 часов, это "для начала". Вполне может быть так, что после понадобится еще 2 дня, чтобы построить план.
Если видите неуверенные взгляды на планировании или по большой разброс в оценке - делайте инвестигейт.
Иногда в разработку приходит сложная фича. Например, рисовать на чужом экране при скриншаринге, как в Slack или Miro.
Если отдать такую на оценку команде, скорее всего, разброс цифр будет космическим, потому что непонятно как ее делать. Один программист даст 40 часов, а другой скажет минимум месяц. Можно, конечно, взять самую большую цифру и закомититься на нее, но даже так есть большой риск не успеть.
Опытный разработчик подскажет, что для сложной задачи нужен инвестигейт (исследование). Попросит полдня-день на изучение вопроса. За это время он почитает стэковерфлоу или документацию, попробует сделать самый сложный кусочек, чтобы понять какие дальше будут затыки, проконсультируется с опытными коллегами, словом, поищет решение.
Результатом такой задачи будет план разработки: дизайн (архитектура) фичи + разбивка на задачи. Конечно, никто не гарантирует закончить за 4-8 часов, это "для начала". Вполне может быть так, что после понадобится еще 2 дня, чтобы построить план.
Если видите неуверенные взгляды на планировании или по большой разброс в оценке - делайте инвестигейт.
Топ каналы о PM
Продолжаю делиться каналами о ПМ, которые читаю сам. Попасть в эту подборку можно только по ❤️.
К сожалению, некоторые каналы из прошлых подборок уже умерли. Поэтому теперь все буду сводить в мега-подборку вот тут: https://telegra.ph/Top-telegramm-kanaly-o-PM-08-03
Из новинок здесь:
- Saturday Night Hack - "светлая сторона" управления разработкой
- Кнопка хорошо - примерно то же, с офигенными картинками и инфостилем
- О бизнес-анализе и не только - все про БА
Больше каналов и их топ посты по ссылке 👇
Продолжаю делиться каналами о ПМ, которые читаю сам. Попасть в эту подборку можно только по ❤️.
К сожалению, некоторые каналы из прошлых подборок уже умерли. Поэтому теперь все буду сводить в мега-подборку вот тут: https://telegra.ph/Top-telegramm-kanaly-o-PM-08-03
Из новинок здесь:
- Saturday Night Hack - "светлая сторона" управления разработкой
- Кнопка хорошо - примерно то же, с офигенными картинками и инфостилем
- О бизнес-анализе и не только - все про БА
Больше каналов и их топ посты по ссылке 👇
Telegraph
Топ телеграмм-каналы о PM
1.FEDOR BORSHEV Советы стыке менеджерского и технического. Зайдет тимлидам и начинающим СТО. Мало спама, мало рекламы, много пользы и свежих идей. Очень рекомендую. Топ посты: Давайте соберем команду и спросим кто что думает Кто отвечает за то, чтобы ПР оказался…
Надо до 6, сможешь?
Представьте, пишет менеджеру Коле его босс:
"Сделай, пожалуйста, пару слайдов про наш отдел. Это для презентации инвестору. Надо до 6, сможешь?". А у Коли до 6 не продохнуть: два звонка с клиентами, собес на айосника и новую фичу надо описать.
Коля может честно сказать "босс, прости, не успею никак". Тогда босс подумает "хм, какой-то Коля непродуктивный, нельзя на него положиться". На следующем перф ревью это сыграет не в пользу Коли.
супер-Коля напишет так: "Да, легко. Только помоги плиз приоритезировать мои другие дела. Есть это, это и вот это. Что выкинуть?". Уже лучше. Босс видит, что Коля в мыле, но хочет помочь. Желание, это хорошо, правда, за него не доплачивают.
супер-мега-Коля сам догадается, что инвестор важнее собеса и отправит на него кого-нибудь из команды. Или требования тестировщику отдаст. Тут уже у босса в голове образуется первая нейронная связь: "Коля = решатель проблем". Вот это ему на руку.
Представьте, пишет менеджеру Коле его босс:
"Сделай, пожалуйста, пару слайдов про наш отдел. Это для презентации инвестору. Надо до 6, сможешь?". А у Коли до 6 не продохнуть: два звонка с клиентами, собес на айосника и новую фичу надо описать.
Коля может честно сказать "босс, прости, не успею никак". Тогда босс подумает "хм, какой-то Коля непродуктивный, нельзя на него положиться". На следующем перф ревью это сыграет не в пользу Коли.
супер-Коля напишет так: "Да, легко. Только помоги плиз приоритезировать мои другие дела. Есть это, это и вот это. Что выкинуть?". Уже лучше. Босс видит, что Коля в мыле, но хочет помочь. Желание, это хорошо, правда, за него не доплачивают.
супер-мега-Коля сам догадается, что инвестор важнее собеса и отправит на него кого-нибудь из команды. Или требования тестировщику отдаст. Тут уже у босса в голове образуется первая нейронная связь: "Коля = решатель проблем". Вот это ему на руку.
Метрики в разработке
В некоторых компаниях успех работы менеджера хотят привязать к цифрам. Это так себе идея, примерно как мерить производительность программиста количеством написанных строк кода. Но если уж OKR внедряют на всю компанию и отвертеться не получится, давайте разберемся какие цифры вообще стоят внимания.
Обещанные задачи vs выполненные - основа для уважения и доверия менеджеру и команде. Показывает, насколько хорошо те умеют оценивать и отвечать за оценки, которые дали.
📈 Как потрекать: Для команды используйте burndown chart или velocity chart. Еще полезно трекать попадание в оценки по каждому индивидуально, чтобы найти лоу-перформеров.
Время на доставку в продакшн (cycle time) - сколько времени проходит с момента начала работы по задаче до поставки в прод. Все простои, неправильные требования, подвисшие пулл реквесты вылезут тут и увеличат время цикла. Чем оно меньше, тем лучше.
📈 Как потрекать: отчет cycle time или control chart в джире.
Счастье команды - самая важная штука, чтобы много и хорошо деливерить. Если программистов не разрывают между 4 проектами, у тестировщиков есть описанные требования, а продактам не вяжут руки, спуская роудмап сверху, то оценки и скорость будут высокими. Эту метрику можно также рассматривать как "зрелость процессов".
📈 Как трекать: Прямо так и спрашивать "насколько ты счастлив на работе от 1 до 10?" на персональных встречах раз в 2 месяца. Оценка 7 и меньше - тревожный звоночек.
Покрытие тестами - без автоматических тестов любой проект быстро погрязнет в регрессии. Больше тестов -> быстрее можно выпускать новые фичи. Неплохое покрытие начинается от 60%.
📈 Как трекать: попросите программистов или AQA, они настроят.
P.S. Тут речь только про технологические метрики. МАУ, ДАУ, ретеншен и другие продуктовые штуки, все еще жизненно необходимы.
P.P.S. Тут я говорю, что метрики как бы и не очень важны, но ладно, потрекаем. Если вы ленивый менеджер, как я, их действительно можно физически не считать, а мерить на глазок. Хотя с цифрами и проще. Тем не менее, пушить команду к счастью, коротким релизам и сдерживанию обещаний надо обязательно.
В некоторых компаниях успех работы менеджера хотят привязать к цифрам. Это так себе идея, примерно как мерить производительность программиста количеством написанных строк кода. Но если уж OKR внедряют на всю компанию и отвертеться не получится, давайте разберемся какие цифры вообще стоят внимания.
Обещанные задачи vs выполненные - основа для уважения и доверия менеджеру и команде. Показывает, насколько хорошо те умеют оценивать и отвечать за оценки, которые дали.
📈 Как потрекать: Для команды используйте burndown chart или velocity chart. Еще полезно трекать попадание в оценки по каждому индивидуально, чтобы найти лоу-перформеров.
Время на доставку в продакшн (cycle time) - сколько времени проходит с момента начала работы по задаче до поставки в прод. Все простои, неправильные требования, подвисшие пулл реквесты вылезут тут и увеличат время цикла. Чем оно меньше, тем лучше.
📈 Как потрекать: отчет cycle time или control chart в джире.
Счастье команды - самая важная штука, чтобы много и хорошо деливерить. Если программистов не разрывают между 4 проектами, у тестировщиков есть описанные требования, а продактам не вяжут руки, спуская роудмап сверху, то оценки и скорость будут высокими. Эту метрику можно также рассматривать как "зрелость процессов".
📈 Как трекать: Прямо так и спрашивать "насколько ты счастлив на работе от 1 до 10?" на персональных встречах раз в 2 месяца. Оценка 7 и меньше - тревожный звоночек.
Покрытие тестами - без автоматических тестов любой проект быстро погрязнет в регрессии. Больше тестов -> быстрее можно выпускать новые фичи. Неплохое покрытие начинается от 60%.
📈 Как трекать: попросите программистов или AQA, они настроят.
P.S. Тут речь только про технологические метрики. МАУ, ДАУ, ретеншен и другие продуктовые штуки, все еще жизненно необходимы.
P.P.S. Тут я говорю, что метрики как бы и не очень важны, но ладно, потрекаем. Если вы ленивый менеджер, как я, их действительно можно физически не считать, а мерить на глазок. Хотя с цифрами и проще. Тем не менее, пушить команду к счастью, коротким релизам и сдерживанию обещаний надо обязательно.
Тестирование в изоляции
В тестировании есть важное правило: 1 фича = 1 энвайронмент. То есть каждое изменение нужно проверять в отдельной, изолированной среде.
Например, у вас банковское приложение и три тестера в команде. Каждый из них проверяет свою фичу, а иногда и несколько одновременно. Еще у вас есть 5 серверов для тестирования, на которых крутится бекенд. Их загрузка выглядит так:
1. QA_1 - выписка за 7 дней - Толя
2. QA_2 - фильтр трат физлицо - Толя
3. QA_3 - быстрый остаток - Паша
4. QA_4 - свободен
5. QA_5 - перевод на свою карту - Кристина
Когда Паше приходит новая фича выписка за 3 дня, он заливает ее на QA_4 и там проверяет. Он тестирует фичу изолированно, от последней версии кода, а значит отыщет все ее баги.
Если Паша вдруг решит залить фичу на QA_1, он рискует что-то пропустить. Код, который он собирается потестить наверняка пересекается с кодом фичи выписка за 7 дней, который уже залит на QA_1. Фича Толи тоже поломается от изменений Паши, т.к. они тестируют близкий фунционал.
Тестируйте в изоляции 😇
В тестировании есть важное правило: 1 фича = 1 энвайронмент. То есть каждое изменение нужно проверять в отдельной, изолированной среде.
Например, у вас банковское приложение и три тестера в команде. Каждый из них проверяет свою фичу, а иногда и несколько одновременно. Еще у вас есть 5 серверов для тестирования, на которых крутится бекенд. Их загрузка выглядит так:
1. QA_1 - выписка за 7 дней - Толя
2. QA_2 - фильтр трат физлицо - Толя
3. QA_3 - быстрый остаток - Паша
4. QA_4 - свободен
5. QA_5 - перевод на свою карту - Кристина
Когда Паше приходит новая фича выписка за 3 дня, он заливает ее на QA_4 и там проверяет. Он тестирует фичу изолированно, от последней версии кода, а значит отыщет все ее баги.
Если Паша вдруг решит залить фичу на QA_1, он рискует что-то пропустить. Код, который он собирается потестить наверняка пересекается с кодом фичи выписка за 7 дней, который уже залит на QA_1. Фича Толи тоже поломается от изменений Паши, т.к. они тестируют близкий фунционал.
Тестируйте в изоляции 😇
Стоимость владения
6 лет назад я купил свою первую машину - бирюзовый мини купер. Спонтанно, эмоционально, за один день. Снял первые и последние $4,000 с карты и обменял на ключи.
В тот момент мне казалось, что купить машину, это то же, что купить велосипед - насобирал денег, заплатил и катаешься. Мир оказался сложней. Теперь надо тратить еще минимум $100 каждый месяц на бензин, мойку, стоянку, масло и так далее по списку. Ауч! 🤦♂️
В разработке точно так же. У любой фичи в продукте есть стоимость владения. Каждая строчка кода, каждый if несет за собой кусок работы. Однажды он сломается и придется чинить баг. Потом проверять, заносить в тест-кейсы, выливать на прод. Двигать тикеты на борде, планировать в спринтах, оправдываться перед клиентами, что у нас не везде такое фиговое качество и так далее по еще большему списку.
По моим внутренним ощущениям, стоимость владения где-то x2 - x3 от стоимости разработки в год (у нас продукт SDK, в б2с, наверное, меньше). То есть, за фичу, на которую потратили 100 часов, придется заплатить за обслуживание еще 200-300 сверху.
А сколько у вас?
6 лет назад я купил свою первую машину - бирюзовый мини купер. Спонтанно, эмоционально, за один день. Снял первые и последние $4,000 с карты и обменял на ключи.
В тот момент мне казалось, что купить машину, это то же, что купить велосипед - насобирал денег, заплатил и катаешься. Мир оказался сложней. Теперь надо тратить еще минимум $100 каждый месяц на бензин, мойку, стоянку, масло и так далее по списку. Ауч! 🤦♂️
В разработке точно так же. У любой фичи в продукте есть стоимость владения. Каждая строчка кода, каждый if несет за собой кусок работы. Однажды он сломается и придется чинить баг. Потом проверять, заносить в тест-кейсы, выливать на прод. Двигать тикеты на борде, планировать в спринтах, оправдываться перед клиентами, что у нас не везде такое фиговое качество и так далее по еще большему списку.
По моим внутренним ощущениям, стоимость владения где-то x2 - x3 от стоимости разработки в год (у нас продукт SDK, в б2с, наверное, меньше). То есть, за фичу, на которую потратили 100 часов, придется заплатить за обслуживание еще 200-300 сверху.
А сколько у вас?
Еще про стоимость владения
Стоимость владения можно и нужно снижать. Ведь чем она меньше, тем больше времени останется на зарабатывание "новых денег" - фичи, исследования, партнерства и тому подобное. Конечно, нулевой она не будет, но хотелось бы тратить на поддержку по минимуму, верно?
Продолжая аналогию с машиной, чтобы не разориться на ремонте нужно заправлять нормальное масло и чиниться на проверенном СТО, а не в гараже у дяди Вани. А вот что экономит часы в разработке:
1. Выкидывать неиспользуемые фичи и код (безжалостно).
Если фича не приносит бизнесу денег, ее надо просто закрыть. Как говорят, лошадь сдохла - слезь.
2. Пользоваться готовыми решениями.
Представьте, что заказчик просит сделать ему клон Тиктока. Среди фич есть съемка и видео редактор - довольно большой кусок проекта. Можно потратить 4 месяца, $300K и кое-как написать его с 0. А можно купить готовый SDK за $30K в год и втянуть к себе за неделю! Прежде чем взяться за новый, масштабный проект, исследуйте, нет ли на рынке готовых решений.
3. Закрывать древние баги.
Если баг не починили, скажем, за год, значит он практически не влияет на бизнес, значит ничего не случится, если его не чинить вообще. Если боитесь потерять ценную инфу, тогда просто перенесите их в отдельный проект. Главное - уберите из основного проекта с глаз долой, чтобы проматывая беклог каждый раз не открывать задачи и не вспоминать "аа, это мы тогда отложили".
4. Писать простые решения.
Про это хочется сказать много, читайте в следующем посте 👇
Стоимость владения можно и нужно снижать. Ведь чем она меньше, тем больше времени останется на зарабатывание "новых денег" - фичи, исследования, партнерства и тому подобное. Конечно, нулевой она не будет, но хотелось бы тратить на поддержку по минимуму, верно?
Продолжая аналогию с машиной, чтобы не разориться на ремонте нужно заправлять нормальное масло и чиниться на проверенном СТО, а не в гараже у дяди Вани. А вот что экономит часы в разработке:
1. Выкидывать неиспользуемые фичи и код (безжалостно).
Если фича не приносит бизнесу денег, ее надо просто закрыть. Как говорят, лошадь сдохла - слезь.
2. Пользоваться готовыми решениями.
Представьте, что заказчик просит сделать ему клон Тиктока. Среди фич есть съемка и видео редактор - довольно большой кусок проекта. Можно потратить 4 месяца, $300K и кое-как написать его с 0. А можно купить готовый SDK за $30K в год и втянуть к себе за неделю! Прежде чем взяться за новый, масштабный проект, исследуйте, нет ли на рынке готовых решений.
3. Закрывать древние баги.
Если баг не починили, скажем, за год, значит он практически не влияет на бизнес, значит ничего не случится, если его не чинить вообще. Если боитесь потерять ценную инфу, тогда просто перенесите их в отдельный проект. Главное - уберите из основного проекта с глаз долой, чтобы проматывая беклог каждый раз не открывать задачи и не вспоминать "аа, это мы тогда отложили".
4. Писать простые решения.
Про это хочется сказать много, читайте в следующем посте 👇
Писать простые решения
Программисты любят писать код. У них это отлично получается, и они хотят применять максимум знаний и навыков на каждом проекте. Использовать новейшие технологии. Сделать систему абсолютно неуязвимой к дефектам. Спроектировать ее так, чтобы она работала стабильно даже на Марсе.
Однако не всем проектам нужна работа на Марсе. Часто бизнес готов сэкономить на Марсе, чтобы система работала ОК хотя бы на небольшом участке Земли. Особенно в стартапах, где каждый доллар на счету.
❗Поэтому надо прогать то, что бизнес просит прямо сейчас, сегодня. Конечно, стоит держать в уме, что может понадобиться в ближайшей перспективе. Но необязательно сразу проектировать на столетия и все случаи жизни.
Представьте, что клиент заказал дейтинг приложение. У него пока нет пользователей, он только запускает новый продукт. Одна из фич приложения - чат. Как ее лучше делать?
Можно взять готовый чат-движок XMPP, развернуть на самом дешевом T2 серваке амазона да прикрутить юай. На все про все уйдет 2 недели. Будет работать кривоватенько, но свою задачу выполнит.
Можно сделать то же самое, но еще прикрутить кеширование, чтоб старые сообщения быстро подгружались, настроить лоад балансер, чтобы выдержать 100К одновременных пользователей, вылизать юай. На такой чат уйдет 2 месяца.
Какой вариант выбрать? Если сервис только запускается и пользователей еще нет, лучше выбрать первый и потратить бюджет на что-то более важное: рекламу или крутой алгоритм мэтчинга. А уже когда сервис взлетит, тогда и будем доводить до ума чат.
В том, чтобы применить нужную сложность есть очень большое мастерство в программировании. И менеджменте.
Программисты любят писать код. У них это отлично получается, и они хотят применять максимум знаний и навыков на каждом проекте. Использовать новейшие технологии. Сделать систему абсолютно неуязвимой к дефектам. Спроектировать ее так, чтобы она работала стабильно даже на Марсе.
Однако не всем проектам нужна работа на Марсе. Часто бизнес готов сэкономить на Марсе, чтобы система работала ОК хотя бы на небольшом участке Земли. Особенно в стартапах, где каждый доллар на счету.
❗Поэтому надо прогать то, что бизнес просит прямо сейчас, сегодня. Конечно, стоит держать в уме, что может понадобиться в ближайшей перспективе. Но необязательно сразу проектировать на столетия и все случаи жизни.
Представьте, что клиент заказал дейтинг приложение. У него пока нет пользователей, он только запускает новый продукт. Одна из фич приложения - чат. Как ее лучше делать?
Можно взять готовый чат-движок XMPP, развернуть на самом дешевом T2 серваке амазона да прикрутить юай. На все про все уйдет 2 недели. Будет работать кривоватенько, но свою задачу выполнит.
Можно сделать то же самое, но еще прикрутить кеширование, чтоб старые сообщения быстро подгружались, настроить лоад балансер, чтобы выдержать 100К одновременных пользователей, вылизать юай. На такой чат уйдет 2 месяца.
Какой вариант выбрать? Если сервис только запускается и пользователей еще нет, лучше выбрать первый и потратить бюджет на что-то более важное: рекламу или крутой алгоритм мэтчинга. А уже когда сервис взлетит, тогда и будем доводить до ума чат.
В том, чтобы применить нужную сложность есть очень большое мастерство в программировании. И менеджменте.
Дать сохранить лицо
Этой штуке я научился совсем недавно у моего тимлида Глеба.
Нам попался очередной нервный заказчик, очень дотошный и требовательный. Один из тех людей, которые пишут "вы мне испортили все приложение!" (а иногда еще и жизнь).
Клиент выносил мозг по каждой мелочи. Найдет съехавшую кнопку и все, тревога, письмо СЕО, бросайте все свои дела и немедленно чините, я не могу выйти в продакшн! Каждое такое сообщение сопровождалось комментариями о нашей компетентности, качестве продукта и все в таком духе. Работать было неприятно.
В один из таких разов, клиент прислал нам ветку с кодом, сказав, что он все сделал по инструкции в сэмпле, но у него ничего не работает и мы опять дебилы. Я попросил тимлида посмотреть ветку, проверить в чем там дело. Оказалось, клиент допустил ошибку в интеграции. Причем банальную, совершенно глупую для программиста ошибку. Условно, скобку не закрыл, хотя в инструкции она была.
Я торжествовал. Вот сейчас, *дорогой клиент*, я поставлю тебя на место, в твоей же любимой ехидно-снисходительной манере. Уже перебирал в голове эпитеты, которыми награжу его, как вдруг позвонил Глеб. "Я написал им в личку, показал где они косякнули. Он проверил код, все, естественно, завелось. Даже извинился (скриншот)".
Попричитав, что Глеб лишил меня приятной мести, на следующий день я был благодарен ему, когда остыл. Он дал клиенту сохранить лицо, и не ввязал нас (и меня в первую очередь) в ненужную войнушку. Клиент с тех пор как будто даже стал меньше козлиться.
Люди не любят выглядеть идиотами. По возможности, уберегайте их от этого.
Этой штуке я научился совсем недавно у моего тимлида Глеба.
Нам попался очередной нервный заказчик, очень дотошный и требовательный. Один из тех людей, которые пишут "вы мне испортили все приложение!" (а иногда еще и жизнь).
Клиент выносил мозг по каждой мелочи. Найдет съехавшую кнопку и все, тревога, письмо СЕО, бросайте все свои дела и немедленно чините, я не могу выйти в продакшн! Каждое такое сообщение сопровождалось комментариями о нашей компетентности, качестве продукта и все в таком духе. Работать было неприятно.
В один из таких разов, клиент прислал нам ветку с кодом, сказав, что он все сделал по инструкции в сэмпле, но у него ничего не работает и мы опять дебилы. Я попросил тимлида посмотреть ветку, проверить в чем там дело. Оказалось, клиент допустил ошибку в интеграции. Причем банальную, совершенно глупую для программиста ошибку. Условно, скобку не закрыл, хотя в инструкции она была.
Я торжествовал. Вот сейчас, *дорогой клиент*, я поставлю тебя на место, в твоей же любимой ехидно-снисходительной манере. Уже перебирал в голове эпитеты, которыми награжу его, как вдруг позвонил Глеб. "Я написал им в личку, показал где они косякнули. Он проверил код, все, естественно, завелось. Даже извинился (скриншот)".
Попричитав, что Глеб лишил меня приятной мести, на следующий день я был благодарен ему, когда остыл. Он дал клиенту сохранить лицо, и не ввязал нас (и меня в первую очередь) в ненужную войнушку. Клиент с тех пор как будто даже стал меньше козлиться.
Люди не любят выглядеть идиотами. По возможности, уберегайте их от этого.