Comments 27
Оценка сроков и стоимости выполнения проекта и оценка времени работы сотрудников – это две разные задачи, на практике не связанные друг с другом. Хотя гипотетически первое должно складываться из суммы второго, но так это не работает. Многие затраты непредсказуемы по своему источнику.
Я лично оцениваю по статистике и не ошибаюсь. В официальных документах это называется “аналого-сопоставительный метод”. В общем, это чисто механический навык, не требующий особых затрат ума, вроде вождения автомобиля. Причём так можно прогнозировать почти что угодно, включая изобретения (разве что великие научные открытия, наверное, нельзя). Но для этого надо хотя бы лет 10 проработать в предметной области.
В деле убегания от медведя необходимо уметь бегать не быстрее медведя, а быстрее своих товарищей.
Я так не считаю. Согласен в части "многие затраты непредсказуемы", но очень важно не потерять суть за частными проблемами: сложность планирования планирования не должна отменять.
Зато если я оцениваю сам (а на высоком уровне я умею оценивать вполне), я не делегирую часть ответственности своей команде. Что позже может привести к проблемам посерьезнее: срыву сроков и ругани в команде. Я с таким сталкивался не раз, когда сейлзы продавали, а тех команда потом ругалась, почему не позвали на оценку проекта??А расскажите как вы делаете именно, интересно? По пулу задач из трекера с усреднением или как то хитрее? И для каких проектов у вас это работает?
Это само собой)
Я ни в коем случае не утверждаю, что нужно отменять планирование или перекладывать его на кого-то другого. И говоря о том, то многие затраты непредсказуемы, я имею в виду, что непредсказуемы сами конкретные затраты. А вот общий объём непредсказуемых затрат и его влияние на проект вполне поддаётся прогнозированию на основании предыдущей статистики. Движение молекул в воздухе тоже непредсказуемо, однако поправку на ветер вполне можно делать.
Я как раз говорю о том, что задачи в трекере сами по себе малопригодны для оценки проекта в целом, так как на низком уровне обстоятельства каждый раз разные. Но в сумме и аналогичные проекты часто находятся, и индивидуальные поправочные коэффициенты к оценкам каждого соисполнителя вполне можно вывести.
Работаю в разработке ПО на заказ в определённой отрасли.
хорошая история, ваш тезис я тоже и слышал, и читал тут, у нас на Хабре.
Давайте я попробую не оппонировать вам, а ответить, что я про это думаю. То есть именно в порядке обмена опытом.
Я, на основании личного опыта, умею оценивать проекты на несколько сотен млн рублей и попадать в оценку по фактическим трудозатратам с точностью до 0.5% (да, есть такой пример в жизни). Но я делаю это основываясь на неявных и неформализованных критериях, которые называются "Экспертная оценка". Формализовать в регламент это я не умею. Если умеете вы - поделитесь таким регламентом. Особенно с учетом того, что я тоже работаю в заказной разработке в куче разных областей и не вижу, как это поддается формализации. Очень интересно, правда
можно даже для интереса рассмотреть проект по созданию какой нить внутренней системы предприятия для обработки заявок, интегрированной с биллингом, HR системой и парочкой других, чтобы понять, а как вы формализуете ее оценку?
Я понимаю, что мы с вами можем вообще говорить о разном: говоря об оценке, я понимаю, что есть минимум три оценки, которые делаю в больших проектах я:
предварительная - на основании бизнес требований
уточненная - на основании уточненных требований, ограничений и допущений
детальная - на базе декомпозиции требований командой разработки
в этой парадигме оценка от исполнителей появится только в части 2 или 3. Но и в части 1 я считаю важным привлекать ответственного от техблока.
Принципиально это важно, поскольку тогда разработчики несут ответственность за решение. Это именно делегирование ответственности в команду и командная игра.
Да, менеджер может сделать все сам (тем более лучше выйдет), но это классика делегирования: один в поле по итогу воин хуже, чем команда. А когда команда или ТехДир или Лид дают оценки, они берут на себя часть ответственности за техническое решение, что есть правильно с тз оргструктуры проекта.
Вы согласитесь или покритикуете такой подход?
Как-то подозрительно мало ссылок на телегу. А вы случаем не человек? 😑
Я оценил вашу иронию, но, действительно, у меня есть канал для менеджеров на котором я не зарабатываю, а который я использую для обсуждения тенденций и проблем в управлении в ИТ. Ничего плохого в том, что я даю на него ссылки не вижу.
А вы по сути согласны или нет, расскажите, и почему?
Давным давно менеджер свято верил, что все проблемы из-за низкой исполнительской дисциплины. Достаточно сделать так, чтобы люди оценивали задачи, исполняли их в срок, и все наладится.
И вот передо мной уникальный результат – бизнес, в котором все задачи исполняются, из них 95 % — в срок. Разве не сказка? Без учета всех этих соплей про влияние техногенной среды на человека.
Все, мечта исполнилась, сейчас эффективность бизнеса взлетит до небес, потому что он превратился в послушную, адаптивную, чутко реагирующую систему. Давай управляй, и все заколосится.
Но не тут-то было.
Первым делом, многие квалифицированные спецы просто уволились.
Во-вторых, в компании поселился страх – не выполнить вовремя поручение, не отреагировать на систему. Страх реальный, сильный. Я точно знаю, потому что плакаться ко мне бегали – «аааа, я не выполнил поручение, помоги, что делать». Пили валидол пачками.
В-третьих, система разделила людей на… Не знаю, как назвать эти категории. Не мудрствуя лукаво, поделю на людей и орков.
(С) https://habr.com/ru/articles/433514/
АД своими руками
Спасибо, отличная история.
Вот что бывает когда айтишники не глядя начинают оцифровывать не IT предприятие. Каждый, кто оцифровывал процессы, сталкивался с таким. Я сталкивался даже не 10 раз, а больше. Автор статьи встретился с этим впервые, а позже несколько изменил свое мнение, что видно из окончания этот статьи:
Поэтому я… Хотел сказать – скрепя сердце, но нет – с огромной радостью и облегчением! – добавляю проверенные элементы контроллинга в систему управления задачами, которую делаю. Сила ведь в интеграции, а не в противопоставлении. Это юношеский максимализм заставляет орать «Scum forever!» или «Дисциплина, и только дисциплина!». А я возьму лучшее – из первого и второго – и добавлю свое, наработанное за 10 лет практики управления задачами.
Золотые слова, которых придерживаюсь и я.
Перечитал статью - да, адок получился ещё тот, но мне кажется что из-за того что вовремя не остановились. До какого-то уровня формализация процессов приносит пользу - вы сами писали что обнаружилась куча неэффективных мест в процессах, халтурящих сотрудников - а потом система стала пожирать людей, чуть ли не физически (увольнения, нервы, орки). Инструмент для анализа ситуации и сбора метрик превратили в карающий орган, и ад начался именно тогда. То что после PS достойно отдельной статьи - а какие элементы оказались полезными, когда стоит остановиться?
Я про то что внедрение регламентов и инструкций сначала увеличивает эффективность работы, потом эффект становится разнонаправленным, но после какого-то момента начинается обратный процесс снижения эффективности, вплоть до драматичного статью бы написал, но к сожалению не писатель.
Гуру менеджмента - Владимир Тарасов - классифицирует такую ситуацию как «кризис рационального управления» и дает лекарство - «управление иррациональное» https://selfengineering.ru/2019/09/27/abstract-8-steps-management-craft/ более подробно изложенное в книге 8 уровней управленческого мастерства. Юные менеджеры страдают, и только начиная с 5го уровня «Руководитель освобождается от раздачи команд и только задаёт вопросы» и начинает понимать в чем суть трекинга задач/времени и как стратегически планировать не имея часовой оценки от каждого исполнителя и не превращая работу в «каторгу».
спросил уже в телеге, спрошу и тут (пусть тоже народ каменты почитает, полезно): и как же это делать? Я понимаю, о чем написано по ссылке и я на последнем месте работы вышел , фактически, на 4й уровень согласно автору, но.
Контроль никто не отменял. И по ссылке нигде не сказано, что данные собирать не нужно. Вы же врядли предлагаете перестать собирать первичку для принятия решений? Или как?
PS: отдельно скажу: если есть проект, который представляет из себя конвеер однотипных задач, если ресурсы проекта не делятся с другими проектами, если команда проекта работает давно и постоянно и на нее можно положиться, я такое могу допустить. Но слишком много "если" получается.
Спасибо за труд.
Критикам - не обязательно соглашаться, просто хорошо оформленное мнение.
спасибо. не, я как раз очень хочу увидеть критику. Потому что на основании моего опыта выкристаллизовался именно этот подход. Именно его я пробовал последние 5 лет на команде 100 человек и получил просто отличные операционные результаты .
Причем я его тестировал и в других командах (продуктовая и внутреннее ИТ), до 400т человек и там тоже было хорошо.
Допускаю, что это не панацея, но я хочу понять. где изъян?
Да, многие отвечают: сложно приучить команду к списаниям, если не списывались никогда (особенно 400 человек сразу). Это ясный аргумент.
Да, многие говорят, что на таком учете данные не до конца точные все равно, но для целей управления - более чем. Там шикарнейшая модель EVM получается , да еще и в реальном времени.
Так почему никто не использует? :)
Фантастика.
Как-то у меня друг работал на фрилансе Upwork с почасовой оплатой. Первое время он каждый день он отрабатывал 8 часов по трекеру. В какой-то момент работодатель снял лимит по трекеру, потому что был в восторге от "перформанса".
Мы компанией иногда собирались у него дома по вечерам. Так вот пока делался кальянчик и кто-то ходил за пивом, он просил меня "покликать". Говорил "поковыряй, пожалуйста, проект; поводи мышкой, полазь по файлам, понабирай что-нибудь на клавиатуре". И так в течении часа стабильно. А на следующий час меня заменял другой друг. Вот тебе и "перфоманс". Так он делал частенько: одной рукой набивал стату в трекере, другой переключал видео не Ютуб.
В реальности он работал часов по 5. А трекал таким образом по 10. И получал деньги за 10. Надо признать, что он талантливый малый и за 5 часов делал столько, сколько у другого разработчика того же грейда заняло бы минимум 10. Но платят за часы... И что, получается ему за 2 раза больше сделанной работы получать столько же, сколько коллеге? Работодатель не хотел этого видеть и удерживал рейт между разработчиками +- равным. Ему казалось, что если повысить одному, то все остальные начнут просить больше. Поэтому мой друг балансировал ситуацию в свою сторону таким вот не совсем честным образом.
Так что надеяться, что сотрудник честно спишет время бессмысленно. Хотите мотивировать сотрудника работать без таких трюков - дайте ему пряник в виде доли. Чтобы его доход реально эависел от результата. Он и сам начнет работать максимально эффективно и другим филонить не даст (т.е. теперь их реальный перфоманс тоже на него влияет). Или кнут - в виде жёсткого контроля и риска потерять работу. Но такое возможно только если на рынке переизбыток соискателей. Или приготовьтесь к немому согласию: работодатель догадывается, что сотрудник не дорабатывает, а сотрудник догадывается, что даже если он разорвется вклочья ради успеха проекта, ему все равно не оплатят это пропорционально его вкладу.
Поэтому он спишет ровно столько, сколько безопасно для него "сорри, сделал все что мог, но не уложились, трагедия" и сколько вы все равно не сможете проверить.
это классическое возражение, мне есть, что на него ответить.
Я работаю в командах разработки 25 лет, я поработал в большом количестве коллективов, где был исполнителем, лидом, РП, руководителем РП.
Большинство исполнителей относятся нормально к учету сделанной работы, особенно если видят, что
до оценки детально не докапываются и есть доверие
если оценка нарушается, человека не обвиняют во всех грехах и срыве проекта
Про этоже я и написал (и не только я): если в команде если доверие, механизм оценок и списаний отлично работает. В вашем примере (а у меня аналогичных тоже много) мне будет пофигу, что фрилансер делает работу за 5 часов, списывая 10. Потому что
а) меня по срокам устраивает
б) меня по бабкам устраивает.
на этом все. И я знаю, что он знает, что я знаю, что он дает с запасом. А я иду на встречу, доверяя ему, иногда давая послабления и тп. Но когда уже у меня будет жопа, он впишется на 100% и поможет уже мне, как я ему до этого. И вот такая команда работает отлично.
Это как раз тот момент, который крайне сложно оцифровать, а может быть и невозможно. И тут должны работать руководители. В вашем примере - его заказчики оказались нормальными ребятами, которые поняли, что результат устраивает и смягчили учет времени.
НО.
это не отменяет необходимости учета в большой компании. Потому что с некоторой точки - это просто необходимость. История, как всегда в поиске баланса: жесткий учет - это зло, отсутствие учета - тоже зло.
Это просто сама по себе нерабочая механика. Вам пофигу, а моему другу нет. Почему бы ему не тратить 5 часов и остальное время нормально жить, а не насильно сидеть у компьютера, чтобы набить часы. Или наоборот отрабатывать все 10, чтобы зарабатывать кратно больше.
Я говорю о том, что списание это только компонент системы. Нужно ещё понимать, что 8 часов работы Васи не равно 8 часам работы Пети. И 8 часов Васи могу давать 70% от велосити команды. А остальные обеспечивает Петя, Леша, Паша.
И может Вася бы хотел работать 5 часов в день и остальное время тратить на жизнь. Он скорее всего так и делает. Но списать 5 часов он не может, он должен списать 8. Вы рассчитываете его перфоманс из 8 часов, он всё ещё больше остальных, но он не реалистичный. Поэтому вы все ещё в непрозрачной системе.
Возможно вы смогли бы мотивировать Васю работать все 8 часов полноценно и получать супер перфоманс на проекте. Но у вас нет системы корреляции вклада на зарплату. Поэтому Вася будет работать 5. А иногда и 3. А трекать 8. По цифрам у вас все красиво, а по факту андерпнрфоманс ключевого сотрудника.
Вот тоже интересно, как это со стороны управленцев выглядит? Почему не принимаются казалось бы логичные решения? Может дело в том, что в случае фул тайм работы сотрудник продает компании своё время, а уж как там его навыки позволяют за это время сделать работу - дело третье.
принимаются. но редко. и, скорее, в небольших компаниях, которые считают время и деньги. В крупных менеджеры заняты получением премий и им уже пофигу, кто и как работает (
Зачем написана была эта статья: до сих по 50% компаний не учитывают нормально время сотрудников. Оно учитывается в экселях или аналогах. И это именно то, о чем коллега выше пишет - у них на бумажке все, типа, красиво, а реально разработка недозагружена до 50% (а то и больше).
Итог - компания недозарабатывает 50% денег и, что важно: сами разработчики недозарабатывают! Потому уже входит в тренд постепенно работа на фулл тайм в двух компаниях (нет ну а фигли, если время есть).
чтобы вы понимали: когда у меня один разраб начал вот так шакалить, мы его за 2 недели вычислили. Он очень сожалел, а мы пояснили, как ему надо работать у нас, чтобы получать больше. И он до сих пор работает (год с тех пор) и получает хор зп.
Короче. Меня самого печалит ситуация, сложившаяся в больших компаниях. Но это шанс для небольших и эффективных :)
Все верно. Идем дальше.
Что, если сотрудник на фрилансе не хочет играть в глупые игры и хочет работать больше и получать больше? Ответ: повысить ставку и закрывать задачи быстрее. Если при этом он на фрилансе не сможет это продать - это вопрос не к исполнению, а к продажам.
Что если сотрудник работает в компании? Ответ: закрывать задачи раньше и просить еще работы у менеджера. Ах нет работы? Идти к линейному и жаловаться, что недозагружен. Сделать это несколько раз. Если всем плевать - это гнилое место и из него надо уходить. Но, как правило, дают ченить прикольное. Или переводят на более сложные проекты.
Теперь про 8 часов Васи != 8 часов Пети. Очевидно, что тут должна быть разница в ставке. И она есть, потому что Вася и Петя получают разные зарплаты. Итого, если Вася в 2 раза быстрее и в 1.5 раза дороже - мне выгоднее Вася. Если разницы нет - сроки решат, но скорее люди (не я, но такова увы практика, выберут подешевле). Это вам ответ из пункта один: если Вася хочет тратить 5 часов на работу, остальное на жизнь - да кто мешает то? Пусть продает себя дороже, если сможет. Это не вопрос учета времени.
Теперь не про фриланс, а про работу, где по ТК надо работать 8 часов. И за это платят зп. Если Вася не хочет работать 8 часов - пусть делает за 5 часов работу на 8. При этом, получая зп условного миддла. Если три часа при этом он будет отдыхать, я не буду против - его ставка невысокая, стоимость невысокая, скорость средняя.
Но я стану против, если Вася попросит поднять зп. Потому что синьору платится зп выше процентов на 30 потому что от него ожидается производительность выше.Теперь про следующий ваш вопрос (он очевидно напрашивается): как оцениваем производительность? Если в часах, это тупо приведет к завышению. Ответ: до конца это оцифровать невозможно. Тут для меня есть человеческий фактор: оценку исполнителя надо иногда проверять. Проверять может лид, РП, СТО - можно делать по разному. Исполнитель и РП должны друг другу доверять. Вот тогда это успешно работает, создавая баланс: исполнители не завышают оценки, если у них адекватные руководители.
У вас нет корреляции перфоманса на зп - кто сказал что нету? Механик тут несколько. К ним есть вопросы, но применяя их с поправкой на п5 выше, можно делать прикольные штуки:
премия по итогам выполненных задач (без возвратов и просрочек)
премия по итогам задач без возвратов (просрочки исключаем, тк ведут к завышениям)
премия по итогу успеха проекта/достижения целей, если попадал в оценки + нет возвратов + высокая оценка от команды.
тут поиграть можно. Да, спорить тоже можно, но механики есть. Тем более с учетом п3.
Подводя итог: наш спор упрется в термин "производительность исполнителя" и надо понимать что это величина только отчасти оцифровывается, так как наши проекты и работы - это не стройка, а , по сути НИОКРы, новая деятельность. Поэтому в любой оценке должен быть человеческий фактор.
Где этого не учитывают - там присуствует описанная вами ситуация. Где учитывают - там вытроен отличный процесс.
На последнем месте у нас команда работала именно так и сами ребята разработчики очень уважали процессы, которые их защищали в части переработок и справедливой оценки по работе.
Это палка о двух сторонах. Если есть хороший спец, но он не умеет себя продавать (это не его главная функция), то работодателю все равно выгодно определять такие кадры и мотивировать их работать на результат.
Уже проходили через такое. Чаще всего всем плевать. А ещё подмешивается политика - делаешь ты, а отчёты директору делает твой РП, лид, PO, Архитектор. И потом они с солидной премией, а у тебя и так ЗП.
Кому очевидно? Вы же меряете часы, а не производительность в час? А ещё лучше менять импакт. Опять же, вам надо, чтобы ресурс выдавал максимальный КПД, или чтобы он себя вам продавал? Если второе, то вы уже этого добились - сколько на рынке дантарьянов с накрученным опытом и профессионально саботирующих работу.
Синьер Вася и синьер Петя и это вообще 2 разных синьера по перфомансу. А ещё может быть ведущий разработчик Леша и он хуже их обоих (ошибка найма). А может быть мидл Саша и по факту оверперформить молча и качественно делая всю грязную работу, позволяя синьерам сфокусироваться на чем-то "более важном" с их точки зрения - код стайл, рефакторинг и ТД.
Пока не найдено ответа на этот вопрос, то вы меряете то, что меряете "(сколько человек сказал вам заняла эта задача / сколько человек вам сказал это займет времени) * коэффициент доверия". Назвать это замером КПД или импакта на результат я не могу. Если вам такие расчеты помогают, это здорово. У меня тоже нет ответа на этот вопрос. Есть только ощущение, что ответ на него даст сразу 2 аутпута: систему оценки влияния на результат и соответственно систему мотивации. Скорее всего у каждого бизнеса и даже направления в бизнесе эти показали будут свои, но это ключ достижению максимального КПД из имеющегося ресурса.
С механиками согласен. Взламывая ваши примеры, сотрудник сможет завышать оценку задачи преднамеренно, и потом соответственно завышать репортинг по часам. Отсюда "коэффициент доверия".
Подводя итог: да, все упирается в КПД и импакт ресурса. Ваша задача как менеджера выжать максимальный КПД из имеющегося ресурса. К кому-то индивидуально применив пряник, а к кому-то кнут. Так и не услышал я, где меряются КПД и импакт. Так что просто хочется предложить вам развивать мысль дальше в этом направлении.
Но раз все счастливы, это здорово.
А давайте я порассуждаю по второй части и синьоров Васю и Петю.
Если, при прочих равных, Петя по трекеру нарушает оценку в 50% случаев на 50% (к примеру), то его цена будет на 25% выше, чем Васи.
Выразится это в стоимости привлечения его на мой проект. У меня, как у РП, будет выбор: взять Васю за 4000/час, который попадет в сроки, которые даст или Петю, который не попадет и будет стоить в итоге 5000/час (он сделает объем за бОльший срок).
Чем не метрика? И основывать ее надо как раз на планфакте. Это вполне импакт - то есть влияние на проект/продукт
Да, узнав про такое (как Петя разработчик), я начну умножать оценки на 2 (и условный Петя именно так и поступал), но тут лечится адекватным РП или Техдиром или лидом, который проводят беседу об адекватности.
Далее Петя идет учиться попадать в разумные оценки. Это полностью аналогично, как я провожу разговоры с офигевшими от страха аналитиками и РП.
Про ведущего разработчика Лешу, который ошибка найма - тоже отлично система работает, мы такого ровно год назад взяли. Выгнали с испыталки, когда он на онбоардинг взял неделю и не смог четко рассказть по дням, что он делал, а потом продолбал задачу на создание архитектуры (оценки, которую сам дал) и декомпозиции задач (тоже сам дал).
Чем не KPI? И опять таки: списание позволило поглядеть направление его мыслей в ходе пристрелочных пары недель, мы еще созванивались и помогали чуваку, не топили. Сам утонул. Итого: попадание в оценки не должно прямо влиять на зп, но как косвенная метрика использоваться должно.
Второе и более четкое по аналитике и разработке - возвраты. Для аналитиков - возвраты на доработку из разработки/QA и тоже самое по разработке.
Да, это потребует хорошей документации, селяви. Она должна быть.
Если вернуться к начальной точке: а что делать разработчику Васе, который умеет работать быстро и без ошибок и хочет получать х2 к текущей зарплате?
ответ 1 из 2х: если компания хорошая и отношения доверительные, рассказать, что он может работать быстрее и брать задачи сложнее, если это (можно и по факту испыталки) оценят. Далее стороны пробуют-смотрят - профит.
если компания плохая то: а) нафиг там вообще сидеть, сложно место сменить чтоли б) сказать что хочешь работать по выходным, делать код в будни а коммитить в выхи. Или просто работать на 2х работах, что тоже самое
Да я понимаю, что конкретно с Вами можно договориться. Если лично Вы мотивированны, то любые инструменты будут работать на благо проекта, Вы сможете извлечь полезную информацию и из списаний и из возвратов. И людьми себя окружите соответствующими и обо всем более менее договоритесь. В каком-то смысле это суть менеджмента.
Я всё-таки больше говорю о каком-то более общем фреймворке. Чтобы был конкретный механизм, когда нет смысла разработчику завышать оценку, например 20 часов, делать за 10, а остальные 10 заниматься своими делами. Т.е..чтобы ему самому было не выгодно это делать. Говоря о контроле техлида или техдира мы всё-таки подразумеваем кнут. Было бы ещё неплохо придумать пряник. Делать работу без возвратов - опция, но возвраты это часть жизни: не учли требования, выяснили что-то в процессе тестирования и тд. Было бы неплохо давать долю. Причем от конкретного продукта. Или давать опцию типа: смотри, мы тебе предлагаем работать по ставке ниже, но в случае успеха проекта даём хороший процент.
В общем механик можно придумать много. Хотелось бы глобального движения именно в направлении "пряника".
понимаю. а нет такого хорошего KPI, мы за 5 лет экспериментов не нашли.
Можно строить на отгруженном обьеме, но тогда станет выгодно его завышать
Можно на качестве и попадании в оценки но тогда а) разработка договаривается с тестированием что было меньше багов, б) начинаются абсурдные требования к докам в) завышения оценок (чтобы попадать)
Можно на успехе проекта, но некоторые проекты стратегические или просто длинные, успеха ждать надо год. Далеко не все готовы быть в роли предпринимателя и год получать , типа 150, чтобы потом получить 1,5 млн (и только в случае успеха). Да и кто решит, успех или нет и что считаем успехом - там тоже вопросики :)
У нас было для разработчиков так: есть фикса тыщ на 10 ниже рынка. И есть премия, которая делится на три (кажется) части и которую может получить разраб
исполнительская дисциплина (это аккуратный перенос задач из спринта в спринт, чтобы в прошлом они не терялись)
возвраты
отработанные полезные часы по трекеру - не менее 32
итог мне нравится: разработчики сами приходят, если нет работы, стараются проверять тикеты перед закрытием сами и сами просят переносить таски в конце недели. За это суммарно пацаны получали типа +30-40 тыщ сверху
Большинству механика нравилась
Как наладить управление ИТ командой, не привлекая внимания санитаров (про оценки и списания)