​Как успевать стендап за 15 минут

1️⃣ Продайте команде проблему. Объявите целью августа начать укладываться в 15 минут.

2️⃣ Начинайте вовремя. Если договорились на 10.00, значит в 10.00 первый человек рассказывает статус. Не задерживайте ни на минуту, даже если пришло 3 человека. Через неделю народ втянется и будет приходить вовремя.

3️⃣ Следуйте формату что сделал - что буду делать - есть ли проблемы.

4️⃣ Для молодых команд добавьте четвертый вопрос - успеваю / не успеваю сделать задачу вовремя, в оговоренные сроки.

5️⃣ ❗Самый важный пункт: каждый раз, когда начинаются лишние детали останавливайте говорящего.
"В 347 таске, по-моему, какая-то херня с требованиями, вчера начал..."
"Саша, стоп, давай обсудим после стендапа"

6️⃣ ❗Самый важный пункт-2: любой затруднительный вопрос, требующий >30 сек разбирайте после стендапа. Т.е. сначала завершили статус, часть ребят ушла, а те, у кого были вопросы, остаются (можно прямо в том же митинге). Да, вы будете оставаться два раза из трех, зато большая часть команды экономит время.

Было: 8 человек слушают претензии Саши по требованиям в 347 таске.
Стало: ПМ, БА и Саша разбирают претензии по требованиям в 347 таске.

7️⃣ Расшарьте экран со списком задач, чтобы соотносить слова Саши с 347 таской. Так всем понятнее о чем идет речь.

--------------------------------------

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

​Новости ПМ совета

3 месяца назад я запустил ПМ совет - сообщество проджектов по решению кейсов.

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

Еще до запуска я думал, как реализовать подписку. Нужен был механизм оплаты, управление пользователями, 2 вида подписки, статистика, в общем целый проект. Хотелось найти готовое решение, желательно, не за миллион денег. Так я обнаружил бот @donate от официальной команды телеграма, он принимает большинство карт и комиссия минимальная.

Нервничал перед запуском подписки - кто ее вообще купит? Какую поставить цену? Но нашлось целых 20 человек, кому формат зашел и почти все ребята продлили ее на 2 месяц. Спасибо вам!! ❤️

Было несколько гостевых встреч, где мы разобрали мое резюме и линкедин с экспертами по найму. Мне кажется, это интересный формат и я хочу его еще покрутить. В сентябре будет одна такая встреча, где построим архитектурную схему (system design) какого-нибудь продукта.

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

Из проблем, которые хочется решить - это невысокая конверсия в подписку - 2%. Если есть идеи, как ее увеличить - пишите в комментах.

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

И приходите на ПМ совет, у нас классно :)

Вчера на совете увлеклись таким вопросом:

В решении споров на чьей стороне должен быть ПМ: команды или клиента? Или может быть выступать таким медиатором, посередине?

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

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

А вы как думаете?

​Тест на технические скилы

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

Так глубоко спрашивают не везде, но на позиции вроде technical product manager или delivery manager довольно часто.

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

https://kavaleuski.me/tech-test

Пишите в комментах сколько набрали.

​Как работать с рисками

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

Объясню на примере.

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

Хороший ПМ увидит в этом потенциальную проблему и пойдет ее решать:

1️⃣ Вспомнит, что Валера говорил на последних ретрах. Какие из его задач были самыми грустными. Проведет 1-1 и выяснит, что Валера устал от проекта за 3 года, но пока еще не созрел уходить. Это идентификация риска.

2️⃣ Если забить на проблему, то с вероятностью 70% Валера уволится. На замену джависта компания потратит примерно $15K. Это анализ риска.

3️⃣ Затем ПМ прикинет варианты решения. Дать Валере других задач или, быть может, перевести на другой проект. А если Валера не вписался в коллектив, и код его так себе, то, может, и нафиг Валеру?

4️⃣ Предположим, другие задачи и проект Валеру не впечатлят, и он решит уйти. Как к этому заранее подготовиться? Потянет ли второй джавист Леша весь проект? Где быстро раздобыть замену? Как дела с документацией? Этот и предыдущий пункты называют смягчение (mitigation) риска.

5️⃣ Валера теперь под прицелом. ПМ будет наблюдать его настроение пристальнее обычного и встречаться с ним раз в неделю. Это мониторинг риска.

Все эти рассуждения ^^ обычно складывают в специальную табличку - реестр рисков. Она создает дополнительный контекст для вашего менеджера или клиента. Им будет чуть понятнее, что происходит на проекте. А в случае пожара можно продемонстрировать свою дальновидность и сказать "я же предупреждал!".

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

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

Вот и весь риск-менеджмент.

Пример джира тикета

Я оформляю задачи вот так. Поясню некоторые поля:

🏷️ Goal + Affected metrics - зачем мы это делаем и на что повлияет.

🏷️ Description - подробное описание, как работает фича, расписан флоу, как работает каждая кнопка.

🏷️ Acceptance Criteria (AC) - главные сценарии, которые надо сделать, чтобы считать задачу выполненной.

🏷️ Subtask - декомпозиция.

🏷️ Time tracking - начальная оценка в часах, сколько времени потратили + есть ли вылет.

🏷️ Assignee - кто сейчас занимается задачей.

🏷️ Development - подтягивает ссылки на коммиты и ветки, удобна фича для разработчиков.

🏷️ Labels - использую для фильтрации на разные темы. Например, фича для клиента (Chingari), к какой части системы относится (FAR-effects), делаем доп. контрактом (CR).

🏷️ Epic link - ссылка на эпик (разбивка системы большими мазками).

🏷️ Fix version - в какой релиз войдет.

--------------------------------

А вы какие поля еще используете?

​Тестовые данные на проде

Однажды я искал дальних родственников на сайте кладбища.

Ради фана вбил в урл /admin. Открылась страница с логином. Недолго думая я ввел admin, admin и....открылась админка.

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

Разблокировав ачивку cool hacker, я написал разработчикам с левого имейла (они не ответили).

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

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

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

Недавно в одном сервисе я ввел промокод test на чекауте и получил год подписки бесплатно (+ coolhacker lvl2). Т.е. для компаний такие косяки могут иметь вполне измеримую стоимость.

​Шаблон для пулл реквестов

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

У ребят из Soundcloud процессы на высоте, они придумали целую систему и заполняют:
📌 описание задачи
📌 детали реализации (тут порефакторили, там добавили новое поле в базу)
📌 скриншот до\после
📌 как тестировать

Это очень хорошие вопросы, о которых надо позаботиться заранее. Без шагов по тестированию QA тратят кучу времени на разбор задачи. А без деталей реализации тимлид долго въезжает в код ревью.

С таким подходом ПРы становятся более предсказуемыми и команда закрывает задачи быстрее, снижая cycle time.

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

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

Работа ПМ в период войны, протестов, мобилизации

В России очередной виток пиздеца. При этом наша с вами работа никуда не делась. От нас по-прежнему ждут релизы, роудмапы и новые фичи.

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

📌 Объясните вашим клиентам, заказчикам и стейкхолдерам, что скорость снизится. Важно не развести руками, мол, извините у нас война, а показать план действий. Есть вот такие-то замены, этот скоуп подсократим, компания делает 1,2,3, чтобы вернуться на прежнюю скорость.

📌 У каждого проекта есть ключевые люди, без которых все ляжет. Если их не перевезли после 24 февраля, спросите, не хотят ли теперь.

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

📌 HR ищут пропавших сотрудников, кто не отметился на дейли. А когда находят, то помогают вернуться в строй. Забрали на сутки, вручили повестку - hr про все в курсе, объясняет как себя вести, какие доки при себе иметь и так далее. Юристы проводят вебинары "что делать, если тебя задержали" и "что говорить в военкомате".

📌 Чаще созванивайтесь с командой. Обсуждайте пусть даже второстепенные, неважные вопросы, просто чтобы отвлечь людей от новостей. Вместе полегче.

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

​How to speak tech

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

Сегодня дополню еще одним - книгой How to speak tech.

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

💾 Виды архитектуры: mvc и 3-tier architecture (вы точно где-то слышали эти слова).

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

💾 Минимум про безопасность: токены, юзер-сессия, sql инъекции, куки, умные урлы. Помните, как в ВК можно было смотреть скрытые фотки, т.к. все альбомы имели определённый урл-паттерн? Жаль они эту книгу не читали.

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

💾 Что такое гитфлоу, все эти мерджи и пулл реквесты объясняют на молоке, яблоках и яйцах, типо закупаемся в магазине.

Если набрали мало баллов в тесте по тех. скиллам, то рекомендую прочитать.

Джуниор менеджеру нужно понимать хотя бы 30% книги. На 80+ вести проект будет комфортно.

Коротко о поиске работы осенью 2022

Кейс: тимлид просит +1К

Вы пишете приложение для фитнеса командой в 12 человек. Работаете через аутсорсинговую фирму, клиент с вами уже 2 года. Результатами он доволен, продукт окупает затраты на разработку, есть амбициозный роудмап.

Раз в год вы проводите перф. ревью для всех сеньоров. Но на этот раз тимлид пришел к вам раньше срока. С прошлого ревью прошло 8 месяцев, тогда вы подняли ему зп на 500$. Теперь он просит поднять еще на тысячу. Говорит, что походил по собесам, и местами предлагают даже на 1,500$ больше, чем сейчас.

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

С рейзом +1К, рентабельность проекта снизится. После повышения для тимлида она будет нулевой, т.е. компания не будет на нем (тимлиде) ни зарабатывать, ни терять.

Что будете делать c рейзом?

Выбрав вариант Предложу дождаться следующего ревью, тимлид с большой вероятностью уйдет.

Сейчас он получает ниже рынка и его запрос вполне справедлив. Он даже не просит максимум из того, что ему предлагают. Да, есть процесс пересмотра раз в год, но зачем ему столько ждать? Свою работу он делает хорошо (почти). Какое ему дело до процессов и бюрократии, когда он в одном шаге от хорошей прибавки? И тем более до рентабельности? Эти вопросы - не его забота.

Но готовы ли мы его потерять?

Разобраться помогут доп. вопросы, многие из которых вы предложили в комментариях (спасибо!):
- Есть ли среди сеньоров кто-то, кто хотел бы стать лидом?
- Поедет ли проект без этого лида, или он тащит команду?
- В каких отношениях заказчик с лидом, доволен ли непосредственно его работой? Будет ли ему больно потерять лида?

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

Вариант Предложу исправить косяки, тогда и поговорим немного лучше. За выслугу лет в ИТ не доплачивают. Зп растет, когда сотрудник повышает свои навыки, которые компания может "перепродать". Раз у тимлида есть косяки, резонно предложить ему их исправить, а после сделать рейз. Но вы все еще платите ниже рынка (это стоит проверить), поэтому большой шанс, что тимлид не согласится на этот вариант и уйдет. Ведь где-то его ждут соблазнительные +$1,500.

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

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

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

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

Что будете делать с рентабельностью?

Давайте прикинем общую рентабельность.

На проекте 12 человек. Если на тимлиде зарабатывали 1,000, то на остальных, в худшем случае, 1,500. Суммарно получается $17,500 в месяц, а после рейза станет на 6% меньше.

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

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

Каждый раз согласовывать новые рейты с клиентом как минимум неудобно. Завтра тестировщик "отправится на поиски сокровищ", а через месяц дизайнер. Бегать каждый раз к клиенту как-то мелочно. Такое только с арендой квартир в Тбилиси работает :)

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

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

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

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

​Моментальная ретроспектива

Каждый раз, когда на проекте происходит любой косяк, я задаю команде один вопрос:
в̶̶̶ы̶̶̶ ̶̶̶ч̶̶̶т̶̶̶о̶̶̶ ̶̶̶о̶̶̶х̶̶̶у̶̶̶е̶̶̶л̶̶̶и̶̶̶?
"что надо сделать, чтобы эта проблема не возникла во второй раз?".

Задача заняла 3 дня вместо 2? Пользователи отрыли какой-то специфичный баг? Упустили кусок стори?

ОК, бывает, но как нам не облажаться в будущем?

Мы не ждём ретроспективы, и разбираем проблемы сразу. Часто, в тот же день. Детали забудутся, накопится ещё пять новых проблем, и мы просто не успеем разобрать каждую хорошо.

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

Я радуюсь этому моменту, потому что он означает, что ребята хорошо справятся уже и без меня 🏝.

​Календарный этикет

Несколько советов, которые сделают из вас английского лорда (или леди) в сфере гугл календаря.

1️⃣ Если пришел непонятный мит, куда вы не хотите идти, напишите организатору "Объясни зачем я там нужен".

2️⃣ Если отменяете или переносите встречу - напишите причину, чтобы люди понимали, что произошло. "Дима болеет, поэтому переносим на след неделю".

3️⃣ Если отклоняете инвайт, напишите письмом (кнопка "email guests") почему не придете, чтобы организатор понимал, почему вы отклонили и что с этим делать. Если неудобное время - используйте propose new time.

4️⃣ Если отправили инвайт и человек его не принял - можно пингануть. Пинговать в этот же день навязчиво, а на следующий - норм.

5️⃣ Не ставьте митинг на сегодня без предупреждения, это "ломает" день. Если очень надо - спросите в лс удобно ли.

6️⃣ Если у вас в середине дня личные дела, то сделайте ивент с названием busy. Так никто не возмутится тем, что в 3 у вас бассейн, и не поставит синк на это время.

7️⃣ Поставьте working hours в своем календаре и расскажите коллегам об этой фиче. Может кому-то миты в 8 утра тоже ОК, а вы боялись так рано ставить.

8️⃣ Не ставьте встречи больше часа.

9️⃣ Агенда. Добавьте 3-5 вопросов, которые будете обсуждать, чтобы человек понимал, о чем пойдет речь.

🔟 Лучшая встреча - та, которой не было. Если можно решить вопрос в почте или тикете - сделайте это. Так наверняка быстрее.

Пишите в комментах, какие у вас календарные обычаи.

​Как ищут баги

Поздним вечер в офисе остались только вы и тестер, остальные ушли на тимбилдинг. В канале urgent тэгают вашу команду и спрашивают все ли в порядке с видео конвертером. Вы открываете аналитику и видите, что метрики упали. Что-то идет не так 😬

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

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

🐞 Попросит у саппорта уточнить у пользователей по каким шагам воспроизводится баг. Видят ли они какую-нибудь ошибку?

🐞 Посмотрит в Mixpanel (аналитика) есть ли зависимость по девайсам, браузерам, ОС, гео.

🐞 Посмотрит в Sentry (мониторинг) есть ли новые ошибки. Да, ошибки есть, но хрен пойми что значат, нужен программист.

🐞 Попробует корнер кейсы: отключит интернет, забьет физическую, оперативную память.

🐞 Попробует воспроизвести с разными форматами файлов. Приложение отработает с .mov, но упадет с .mp4. Кажется, дело в этом.

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

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

​Нужен ли трекинг времени

Нет, не нужен.

Давате расскажу почему.

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

1️⃣ Следить за прибыльностью проекта (profits & loss).

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

Чем больше часов выставим, тем больше будет прибыль компании. При этом потратить надо как можно меньше часов. Чтобы вести этот бюджет, программистов просят логать время на таски. Они плюются, но по-другому никак.

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

Так же и в продукте.

2️⃣ Считать попадание команды в свои оценки.

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

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

3️⃣ Контролировать, что человек работает весь день.

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

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

Но это, конечно, самообман. Менеджеры умеют придумать 100 причин, как обосновать x3 эстимейт для заказчика. Программисты придумают 200. И такие, что даже не придерешься.

--------------------------------------

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

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

А вы?