Баланс экспертизы в команде
На своей первой работе я думал: "тут все молодые, неопытные (как и я), поэтому мы вечно не успеваем. Приду в место посерьезнее, там будут одни сеньоры, рутинно щелкающие проекты".
В месте посерьезнее ситуация стала лучше, но кардинально не изменилась. Джуны были и здесь! Зато теперь на каждом проекте есть главный программист, который шарит в кодовой базе и в каждом ее методе. Для него сложность этого проекта - в самый раз. Сложнее - уже не потянул бы; легче - заскучал.
Например, на проекте умный собачий ошейник было много трудных задач, которые на стэковерлоу не нагуглишь. Надо было разбираться в специальном протоколе 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 месяца.
Какой вариант выбрать? Если сервис только запускается и пользователей еще нет, лучше выбрать первый и потратить бюджет на что-то более важное: рекламу или крутой алгоритм мэтчинга. А уже когда сервис взлетит, тогда и будем доводить до ума чат.
В том, чтобы применить нужную сложность есть очень большое мастерство в программировании. И менеджменте.
Дать сохранить лицо
Этой штуке я научился совсем недавно у моего тимлида Глеба.
Нам попался очередной нервный заказчик, очень дотошный и требовательный. Один из тех людей, которые пишут "вы мне испортили все приложение!" (а иногда еще и жизнь).
Клиент выносил мозг по каждой мелочи. Найдет съехавшую кнопку и все, тревога, письмо СЕО, бросайте все свои дела и немедленно чините, я не могу выйти в продакшн! Каждое такое сообщение сопровождалось комментариями о нашей компетентности, качестве продукта и все в таком духе. Работать было неприятно.
В один из таких разов, клиент прислал нам ветку с кодом, сказав, что он все сделал по инструкции в сэмпле, но у него ничего не работает и мы опять дебилы. Я попросил тимлида посмотреть ветку, проверить в чем там дело. Оказалось, клиент допустил ошибку в интеграции. Причем банальную, совершенно глупую для программиста ошибку. Условно, скобку не закрыл, хотя в инструкции она была.
Я торжествовал. Вот сейчас, *дорогой клиент*, я поставлю тебя на место, в твоей же любимой ехидно-снисходительной манере. Уже перебирал в голове эпитеты, которыми награжу его, как вдруг позвонил Глеб. "Я написал им в личку, показал где они косякнули. Он проверил код, все, естественно, завелось. Даже извинился (скриншот)".
Попричитав, что Глеб лишил меня приятной мести, на следующий день я был благодарен ему, когда остыл. Он дал клиенту сохранить лицо, и не ввязал нас (и меня в первую очередь) в ненужную войнушку. Клиент с тех пор как будто даже стал меньше козлиться.
Люди не любят выглядеть идиотами. По возможности, уберегайте их от этого.
Этой штуке я научился совсем недавно у моего тимлида Глеба.
Нам попался очередной нервный заказчик, очень дотошный и требовательный. Один из тех людей, которые пишут "вы мне испортили все приложение!" (а иногда еще и жизнь).
Клиент выносил мозг по каждой мелочи. Найдет съехавшую кнопку и все, тревога, письмо СЕО, бросайте все свои дела и немедленно чините, я не могу выйти в продакшн! Каждое такое сообщение сопровождалось комментариями о нашей компетентности, качестве продукта и все в таком духе. Работать было неприятно.
В один из таких разов, клиент прислал нам ветку с кодом, сказав, что он все сделал по инструкции в сэмпле, но у него ничего не работает и мы опять дебилы. Я попросил тимлида посмотреть ветку, проверить в чем там дело. Оказалось, клиент допустил ошибку в интеграции. Причем банальную, совершенно глупую для программиста ошибку. Условно, скобку не закрыл, хотя в инструкции она была.
Я торжествовал. Вот сейчас, *дорогой клиент*, я поставлю тебя на место, в твоей же любимой ехидно-снисходительной манере. Уже перебирал в голове эпитеты, которыми награжу его, как вдруг позвонил Глеб. "Я написал им в личку, показал где они косякнули. Он проверил код, все, естественно, завелось. Даже извинился (скриншот)".
Попричитав, что Глеб лишил меня приятной мести, на следующий день я был благодарен ему, когда остыл. Он дал клиенту сохранить лицо, и не ввязал нас (и меня в первую очередь) в ненужную войнушку. Клиент с тех пор как будто даже стал меньше козлиться.
Люди не любят выглядеть идиотами. По возможности, уберегайте их от этого.
PM стрим со мной
На прошлой неделе сходил на стрим о ПМстве в роли спикера.
Там у всех директорские роли (кроме меня 🙊). Это как раз те, кто сегодня нанимает проджектов в Минске. Если думаете менять работу, то обязательно послушайте кого ищут в 2021 из первых уст.
Темы все насущные:
- как стать PM, что делать, кого читать и у кого поучиться;
- что происходит с методологиями в пандемию;
- роль Delivery manager и чем она отличается от PM;
Запись можно посмотреть тут: https://youtu.be/7vxs9ClL-Vs
На прошлой неделе сходил на стрим о ПМстве в роли спикера.
Там у всех директорские роли (кроме меня 🙊). Это как раз те, кто сегодня нанимает проджектов в Минске. Если думаете менять работу, то обязательно послушайте кого ищут в 2021 из первых уст.
Темы все насущные:
- как стать PM, что делать, кого читать и у кого поучиться;
- что происходит с методологиями в пандемию;
- роль Delivery manager и чем она отличается от PM;
Запись можно посмотреть тут: https://youtu.be/7vxs9ClL-Vs
YouTube
Современный Project Management
Обсудили с лидерами PM-индустрии 3 волны Agile, Delivery Management и менторство.
В закрепленном комментарии полезные ссылки.
⌛️ Таймкоды:
00:00 Знакомство
02:33 Классические подходы в управлении - Agile
05:36 2 модели применения Agile
12:14 Как живется…
В закрепленном комментарии полезные ссылки.
⌛️ Таймкоды:
00:00 Знакомство
02:33 Классические подходы в управлении - Agile
05:36 2 модели применения Agile
12:14 Как живется…
"Ясно, понятно"
- это последняя книга Максима Ильяхова, автора "Пиши, сокращай" и "Новые правила деловой переписки".
Я очень советую ее прочитать менеджерам и всем, кто работает с клиентами. Она помогает прокачать наш самый важный навык - коммуникацию.
В книге много примеров того, как быть удобным для собеседника. Она учит задавать правильные вопросы самому себе, прежде чем вообще что-то сказать:
- какой контекст у человека? что ему надо объяснять, а что он, по идее, знает? насколько он технически подкован?
- какие у него интересы? что для него будет важно, а какую инфу можно опустить?
Представьте, что делаете спринт репорт для своего босса. Там допустимо написать, что программисты балбесы (бывает и такое). Но этот же самый отчет у заказчика вызовет недоумение. Жалуетесь на своих собственных программистов? Для клиента такая версия отчета не пойдет, в ней много внутряка, который ему знать не нужно.
Берегите контекст, читайте "Ясно, понятно".
- это последняя книга Максима Ильяхова, автора "Пиши, сокращай" и "Новые правила деловой переписки".
Я очень советую ее прочитать менеджерам и всем, кто работает с клиентами. Она помогает прокачать наш самый важный навык - коммуникацию.
В книге много примеров того, как быть удобным для собеседника. Она учит задавать правильные вопросы самому себе, прежде чем вообще что-то сказать:
- какой контекст у человека? что ему надо объяснять, а что он, по идее, знает? насколько он технически подкован?
- какие у него интересы? что для него будет важно, а какую инфу можно опустить?
Представьте, что делаете спринт репорт для своего босса. Там допустимо написать, что программисты балбесы (бывает и такое). Но этот же самый отчет у заказчика вызовет недоумение. Жалуетесь на своих собственных программистов? Для клиента такая версия отчета не пойдет, в ней много внутряка, который ему знать не нужно.
Берегите контекст, читайте "Ясно, понятно".
Обещать меньше, делать больше
Когда я начинал работать ПМом мне тяжело давались переговоры с клиентами. Боялся, что заказчик подумает что мы лохи, не умеем делать сайты, развернется и уйдет. Всегда хотелось выглядеть представителем серьезной, опытной студии, использовать крутые технологии. Например, делать А/Б тесты.
На деле, разрабатывая сайты с бюджетом в 160 часов, ни на какие хотелки и А/Б тесты времени не остается. Задача ПМа в этом случае - сослаться на ограниченность бюджета и строго охранять проданный скоуп. Прости, дорогой заказчик.
У меня это не всегда получалось. Иногда клиент просил что-то мелкое и само собой разумеющиеся. Я входил в положение и брал в работу. В результате страдали бюджет компании или поставка. В обоих случаях, это была моя вина.
Сейчас я это понимаю, и чаще говорю "нет", чем "да". В конечном итоге выгоднее быть честными в том, что мы точно можем сделать, а что может-быть-влезет-в-самом-конце-если-останется-бюджет. Потому что, когда клиент замечает разницу между обещанием и поставкой, он расстраивается и винит команду.
Иногда звезды сходятся и в конце проекта остается немного времени и бюджета. И если потратить его на хотелки клиента, он надолго это запомнит и будет рекомендовать нас другим. Даже старые косяки забудутся.
Когда я начинал работать ПМом мне тяжело давались переговоры с клиентами. Боялся, что заказчик подумает что мы лохи, не умеем делать сайты, развернется и уйдет. Всегда хотелось выглядеть представителем серьезной, опытной студии, использовать крутые технологии. Например, делать А/Б тесты.
На деле, разрабатывая сайты с бюджетом в 160 часов, ни на какие хотелки и А/Б тесты времени не остается. Задача ПМа в этом случае - сослаться на ограниченность бюджета и строго охранять проданный скоуп. Прости, дорогой заказчик.
У меня это не всегда получалось. Иногда клиент просил что-то мелкое и само собой разумеющиеся. Я входил в положение и брал в работу. В результате страдали бюджет компании или поставка. В обоих случаях, это была моя вина.
Сейчас я это понимаю, и чаще говорю "нет", чем "да". В конечном итоге выгоднее быть честными в том, что мы точно можем сделать, а что может-быть-влезет-в-самом-конце-если-останется-бюджет. Потому что, когда клиент замечает разницу между обещанием и поставкой, он расстраивается и винит команду.
Иногда звезды сходятся и в конце проекта остается немного времени и бюджета. И если потратить его на хотелки клиента, он надолго это запомнит и будет рекомендовать нас другим. Даже старые косяки забудутся.
Какие отчеты делает менеджер
Никто, конечно, не любит отчеты, но они - часть нашей работы. Поэтому сегодня разбираем только обязательные для продукта и аутсорса. Поехали:
1️⃣ Sprint report. Что сделали за последние 2 недели, что не сделали, всякие графики, риски. Пример.
2️⃣ Потраченный бюджет для клиента. В этом отчете говорится сколько часов и денег потратила команда на задачи в проекте за период. Обычно делается раз в месяц, чтобы на его основе выставить счет клиенту. Пример.
3️⃣ Потраченные часы сотрудников для компании. Почти то же, что и предыдущий, но с поправками на невыставленные часы. Иногда бывает так, что за некоторые работы, клиент не платит. Например, если в фикс-прайс контракте прописан месяц поддержки. Тогда команда чинит баги после релиза бесплатно. Эту разницу "выставлено клиенту" / "сделано бесплатно" надо учитывать для финансистов компании, что и отражает этот отчет. В продукте его тоже делают, чтобы посчитать затраты на собственную разработку.
4️⃣ Incident report. Когда на продакшене беда, все суетятся и думают как починить проблему. На следующий день, когда страсти поутихнут, надо подвести итоги потерь. Пример недавнего аутэджа у Фейсбука.
5️⃣ Отчет по разработанным фичам. Иногда работаешь на российскую фирму, а деньги из апстора (или от клиента) приходят на дочернюю компанию, например, в США. Так делают, чтобы не держать деньги в наших банках. Так вот, в этом случае российское юрлицо передает права на разработку американскому, как будто одна фирма наняла другую. Отчет странный, но встречается часто.
Эти репорты ПМ делает постоянно. Но иногда просят сделать что-то кастомное, например, по качеству или успеваемости поставки. Поэтому важно иметь хороший спринт репорт, который покрывает все основные проектные темы.
Никто, конечно, не любит отчеты, но они - часть нашей работы. Поэтому сегодня разбираем только обязательные для продукта и аутсорса. Поехали:
1️⃣ Sprint report. Что сделали за последние 2 недели, что не сделали, всякие графики, риски. Пример.
2️⃣ Потраченный бюджет для клиента. В этом отчете говорится сколько часов и денег потратила команда на задачи в проекте за период. Обычно делается раз в месяц, чтобы на его основе выставить счет клиенту. Пример.
3️⃣ Потраченные часы сотрудников для компании. Почти то же, что и предыдущий, но с поправками на невыставленные часы. Иногда бывает так, что за некоторые работы, клиент не платит. Например, если в фикс-прайс контракте прописан месяц поддержки. Тогда команда чинит баги после релиза бесплатно. Эту разницу "выставлено клиенту" / "сделано бесплатно" надо учитывать для финансистов компании, что и отражает этот отчет. В продукте его тоже делают, чтобы посчитать затраты на собственную разработку.
4️⃣ Incident report. Когда на продакшене беда, все суетятся и думают как починить проблему. На следующий день, когда страсти поутихнут, надо подвести итоги потерь. Пример недавнего аутэджа у Фейсбука.
5️⃣ Отчет по разработанным фичам. Иногда работаешь на российскую фирму, а деньги из апстора (или от клиента) приходят на дочернюю компанию, например, в США. Так делают, чтобы не держать деньги в наших банках. Так вот, в этом случае российское юрлицо передает права на разработку американскому, как будто одна фирма наняла другую. Отчет странный, но встречается часто.
Эти репорты ПМ делает постоянно. Но иногда просят сделать что-то кастомное, например, по качеству или успеваемости поставки. Поэтому важно иметь хороший спринт репорт, который покрывает все основные проектные темы.
Project vs Program manager
Если вы присматривались к работе в продуктовой компании за пределами СНГ, то замечали, как редко там встречается должность project manger. ПМов на западе действительно меньше.
Обычно их заменяют связкой engineering manager (тимлид + немного менеджерских обязанностей) + product manager.
В больших продуктах есть похожая на проджекта роль - program manager. Это человек, который отвечает за большую инициативу, в рамках которой делают несколько проектов. Например, программ в Gmail может отвечать за интеграцию гугл рекламы Adwords и координировать работу 2 команд из разных продуктов - Adwords и Gmail.
Его миссия - связывать несколько команд единой стратегией и целью. Он асайнит людей на проекты, запускает новые, синхронизирует их работу, чтобы получить согласованный результат на выходе.
На прошлой работе я был как раз програмным менеджером. Мы делали продукт по поиску списывальшиков на онлайн экзаменах силами шести команд. Одна делала интеграцию с LMS, другая интерфейс для ревизоров, третья - онбординг для университетов и так далее. Всеми этими проектами управляло 2 менеджера, которых курировал я.
Это интересная работа, если вы устали от операционки на уровне баг-стори и готовы к масштабу уровня релиз-роудмап.
В блоге Atlassian очень понятно объяснили, чем отличаются эти две роли:
Если вы присматривались к работе в продуктовой компании за пределами СНГ, то замечали, как редко там встречается должность project manger. ПМов на западе действительно меньше.
Обычно их заменяют связкой engineering manager (тимлид + немного менеджерских обязанностей) + product manager.
В больших продуктах есть похожая на проджекта роль - program manager. Это человек, который отвечает за большую инициативу, в рамках которой делают несколько проектов. Например, программ в Gmail может отвечать за интеграцию гугл рекламы Adwords и координировать работу 2 команд из разных продуктов - Adwords и Gmail.
Его миссия - связывать несколько команд единой стратегией и целью. Он асайнит людей на проекты, запускает новые, синхронизирует их работу, чтобы получить согласованный результат на выходе.
На прошлой работе я был как раз програмным менеджером. Мы делали продукт по поиску списывальшиков на онлайн экзаменах силами шести команд. Одна делала интеграцию с LMS, другая интерфейс для ревизоров, третья - онбординг для университетов и так далее. Всеми этими проектами управляло 2 менеджера, которых курировал я.
Это интересная работа, если вы устали от операционки на уровне баг-стори и готовы к масштабу уровня релиз-роудмап.
В блоге Atlassian очень понятно объяснили, чем отличаются эти две роли:
This media is not supported in your browser
VIEW IN TELEGRAM
Буддисты и автоматизация
Это буддийский молитвенный барабан. На его поверхность наносят тексты священных писаний. Считается, что когда покрутишь барабан, то молитва как будто прочиталась.
Буддисты прошаренные. Зачем читать одну молитву в минуту, если можно сразу 30? Прогулялся вдоль храма, накрутил десяток барабанов, нахлопотал здоровья, денег и чего еще хочешь.
Покажите молитвенный барабан коллегам из соседнего отдела, которые до сих пор делают отчеты по аналитике вручную.
Это буддийский молитвенный барабан. На его поверхность наносят тексты священных писаний. Считается, что когда покрутишь барабан, то молитва как будто прочиталась.
Буддисты прошаренные. Зачем читать одну молитву в минуту, если можно сразу 30? Прогулялся вдоль храма, накрутил десяток барабанов, нахлопотал здоровья, денег и чего еще хочешь.
Покажите молитвенный барабан коллегам из соседнего отдела, которые до сих пор делают отчеты по аналитике вручную.
Ходить по собесам
Давайте вскроем ящик Пандоры. Зазорно ли ходить на собеседования в другие компании, когда уже есть работа?
Я думаю, что нет, т.к. мы с вами на рынке труда, со всеми вытекающими последствиями. Работа - не романтические отношения, где любовь до гроба и пока смерть не разлучит нас. Поэтому распространенный аргумент о лояльности компании все-таки мимо. Такие устои морально устарели, сейчас все меняют работу раз в 2-3 года (не берем в рассмотрение директорские роли и выше, для них другие правила игры). Ну и если компания с тобой честна, то никак не пострадает от того, что ты выяснишь свое положение на рынке.
На самом деле ходить по собесам и общаться с рекрутерами полезно. Это дает несколько важных штук:
1️⃣ Уверенность в себе и завтрашнем дне. Когда поступает пару предложений в месяц, то понимаешь, что не пойдешь по миру, если на текущем месте что-то пойдет не так. Так избавляешься от зачатков синдрома самозванца, когда думаешь, что компания делает тебе одолжение, давая работу.
2️⃣ Знание своей стоимости на рынке. Когда тебе предлагают +-300 долларов в районе текущей зп, то все ОК. Значит, сейчас ты получаешь свою честную, рыночную зп. Всегда будут места, где трава чуть зеленее. А вот если предлагают +700 и больше, и сразу в нескольких компаниях, то есть повод задуматься. Цифры условные, у всех разная зп, лучше, конечно, в процентах считать.
3️⃣ Понимание, каких знаний сейчас не хватает до следующего карьерного скачка. Иногда собеседование заканчивается отказом. Это нормально. Когда получаешь отказ, значит недотягиваешь до позиции, на которую хочешь. Отлично! По вопросам, которые задают, и финальному фидбеку можно хорошо порефлексировать и составить план роста.
Мне хватает 2-3 интервью в год, чтобы иметь более-менее ясное представление о себе и "оставаться в форме".
А вам?
Давайте вскроем ящик Пандоры. Зазорно ли ходить на собеседования в другие компании, когда уже есть работа?
Я думаю, что нет, т.к. мы с вами на рынке труда, со всеми вытекающими последствиями. Работа - не романтические отношения, где любовь до гроба и пока смерть не разлучит нас. Поэтому распространенный аргумент о лояльности компании все-таки мимо. Такие устои морально устарели, сейчас все меняют работу раз в 2-3 года (не берем в рассмотрение директорские роли и выше, для них другие правила игры). Ну и если компания с тобой честна, то никак не пострадает от того, что ты выяснишь свое положение на рынке.
На самом деле ходить по собесам и общаться с рекрутерами полезно. Это дает несколько важных штук:
1️⃣ Уверенность в себе и завтрашнем дне. Когда поступает пару предложений в месяц, то понимаешь, что не пойдешь по миру, если на текущем месте что-то пойдет не так. Так избавляешься от зачатков синдрома самозванца, когда думаешь, что компания делает тебе одолжение, давая работу.
2️⃣ Знание своей стоимости на рынке. Когда тебе предлагают +-300 долларов в районе текущей зп, то все ОК. Значит, сейчас ты получаешь свою честную, рыночную зп. Всегда будут места, где трава чуть зеленее. А вот если предлагают +700 и больше, и сразу в нескольких компаниях, то есть повод задуматься. Цифры условные, у всех разная зп, лучше, конечно, в процентах считать.
3️⃣ Понимание, каких знаний сейчас не хватает до следующего карьерного скачка. Иногда собеседование заканчивается отказом. Это нормально. Когда получаешь отказ, значит недотягиваешь до позиции, на которую хочешь. Отлично! По вопросам, которые задают, и финальному фидбеку можно хорошо порефлексировать и составить план роста.
Мне хватает 2-3 интервью в год, чтобы иметь более-менее ясное представление о себе и "оставаться в форме".
А вам?
Ходите на собесы, когда не собираетесь менять работу?
Anonymous Poll
4%
Хожу больше 6 раз в год
6%
Хожу 3-5 раз в год
26%
Хожу пару раз в год
64%
Не хожу
Неприкосновенность оценки
В зрелых инженерных организациях есть принцип неприкосновенности оценки. То есть то, что команда оценила в 2 месяца, ставится в план как 2 месяца. Нельзя просто придти и сказать, "мне пофигу, сделаете за месяц". Нет никакого смысла ставить месяц, все равно ведь не сделают.
Когда сейл и прод действуют сообща, понимая, что гребут в одной лодке, клиент остается довольным. Как ни странно, но ИТ бизнес тоже растет благодаря сарафанному радио и отзывам. Поэтому последнее слово в оценках остается за технарями.
В других компаниях следуют противоположной тактике. Сейлы оценивают проекты сами, исходя из платежеспособности клиента. А когда передают контракт в продакшн, он нередко заваливается по срокам из-за неточной оценки. Клиент уходит расстроенный, а сейлы ищут новую "жертву", благо, рынок огромный. Такие фирмы обычно небольшие, до 50 человек, (репутационные потери просто не дают вырасти) и с активной текучкой сотрудников.
Интересно, как обстоят дела в очень зрелых инженерных организациях, вроде Тесла или Эпл? Ведь атмосфера страха и высокая конкуренция на короткой дистанции все же дают результат.
Всем известно, что Стив Джобс, например, тот еще булли. Он уволил чувака, который засомневался, что тот сможет создать коммерчески успешную мышку. Возможно, благодаря такому подходу Эпл и создала столько крутых продуктов. Говорит ли Илон Маск "мне похер как эта штука взлетит, но за 3 недели, или вы все уволены"?
В зрелых инженерных организациях есть принцип неприкосновенности оценки. То есть то, что команда оценила в 2 месяца, ставится в план как 2 месяца. Нельзя просто придти и сказать, "мне пофигу, сделаете за месяц". Нет никакого смысла ставить месяц, все равно ведь не сделают.
Когда сейл и прод действуют сообща, понимая, что гребут в одной лодке, клиент остается довольным. Как ни странно, но ИТ бизнес тоже растет благодаря сарафанному радио и отзывам. Поэтому последнее слово в оценках остается за технарями.
В других компаниях следуют противоположной тактике. Сейлы оценивают проекты сами, исходя из платежеспособности клиента. А когда передают контракт в продакшн, он нередко заваливается по срокам из-за неточной оценки. Клиент уходит расстроенный, а сейлы ищут новую "жертву", благо, рынок огромный. Такие фирмы обычно небольшие, до 50 человек, (репутационные потери просто не дают вырасти) и с активной текучкой сотрудников.
Интересно, как обстоят дела в очень зрелых инженерных организациях, вроде Тесла или Эпл? Ведь атмосфера страха и высокая конкуренция на короткой дистанции все же дают результат.
Всем известно, что Стив Джобс, например, тот еще булли. Он уволил чувака, который засомневался, что тот сможет создать коммерчески успешную мышку. Возможно, благодаря такому подходу Эпл и создала столько крутых продуктов. Говорит ли Илон Маск "мне похер как эта штука взлетит, но за 3 недели, или вы все уволены"?