Рабочее время: кошелек или жизнь?
Проблемы учета рабочего времени обсуждались не раз и не два. При этом мнение о необходимости таймтрекинга разделяет сотрудников на два противоположных лагеря. Как правило, исполнители всячески осуждают и указывают на неэффективность проектов, в которых необходимо вести учет рабочего времени и ежедневно отчитываться о проделанной работе. Напротив, многие правильные руководители приводят множество доводов в пользу таймтрекинга своих сотрудников. Это противоречие порой вызывает у меня приступы сильной головной боли, которую я попытался унять написанием этой статьи. Есть такое лекарство – мышление письмом...
Мелочи жизни
С возрастом до меня постепенно стала доходить важность небольших отличий. Вот, например, два человека. Они почти одинаковы. Руки, ноги, туловище, голова... Есть, правда, небольшие конструктивные особенности, потому что один человек – это женщина, а другой– мужчина... А красивая женщина от некрасивой по комплектации вообще ничем не отличается. По внешним признакам вообще не отличишь умного от глупого, труса от храбреца, бедного от богатого, доброго от злого, подонка от человека чести.
Когда-то я читал, что синоби многолетними тренировками превращали свое тело в живое оружие. Детей подвергали жестоким и весьма болезненным процедурам с целью добиться свободного расчленения суставов. В фехтовании расчленение сустава позволяло на полтора-два сантиметра удлинить руку при ударе. Раньше мне казалось, что это несоразмерная плата за годы изнурительных тренировок. Однако с приобретением жизненного опыта я осознал разницу в ударах холодным оружием, которые наносятся в миллиметре от горла или на два сантиметра глубже. Постепенно жизнь изменила мое отношение к мелочам.
Заметить мелочи бывает непросто. Парадокс, но для того, чтобы заметить небольшую разницу, надо просмотреть много материала. Наверное, поэтому впереди будет много слов об общеизвестных истинах. Не дайте себя обмануть. Следите за движениями рук...
Однако если у вас на проекте и без ведения учета рабочего времени все хорошо, не стоит тратить свое время и забивать себе голову проблемами этой статьи. От тех, кто все-таки решится прочитать, надеюсь получить конструктивную критику.
Про патроны
- Товарищ замполит! Патроны кончились!
- Но ты же коммунист!
И пулемет застрочил с новой силой...
Однажды я присутствовал на встрече, посвященной обмену опытом использования JIRA. Коллеги категорически не применяли на своих проектах повременную отчетность. Ответ руководителя проекта на мой вопрос: «Почему?», заданный в частном порядке, был несколько неожиданным. «Дело в том, - честно признался он, - что учет рабочего времени - это палка о двух концах. Часто мои сотрудники работают больше 8 часов, и если они будут учитывать время, рано или поздно встанет вопрос об оплате переработок». «Да уж, - подумал я, - здесь явно не слышали про двенадцатый принцип экстремального программирования ».
Несколько лет назад я работал руководителем лаборатории программирования в одном научно-исследовательском учреждении. Наши ученые не торопили мою команду, и поэтому у меня появилась возможность безболезненно поэкспериментировать с различными методологиями организации разработки программного обеспечения. Это был единственный случай в моей практике, когда мне удалось убедиться в волшебной силе XP-программирования. К сожалению, ни до, ни после данный подход не удалось применить ни на одном из моих проектов. Одним из обязательных условий эффективного применения данного метода, по словам одного из основателей данного подхода Кента Бека , является необходимость одновременного соблюдения всех двенадцати принципов XP. В противном случае результаты применения данной методологии могут вас сильно огорчить.
Я решил не разочаровываться. Однако, к моему удивлению, одним из самых трудных моментов стала необходимость соблюдать 40-часовую рабочую неделю. И для себя любимого тоже. Этот принцип входил в явное противоречие с распространенным тезисом о том, что у начальника на все должно хватать чужого времени . Подсознание руководителя отчетливо понимало, что в сутках не может быть больше 24 часов, однако напрочь отказывалось признавать, что рабочий день сотрудника не может превышать 8 часов. Ведь задачи должны быть решены еще вчера!!! Я вдруг явственно ощутил, что чужое рабочее время - это ресурс. И этот ресурс ограничен.
Серебряная пуля?
Есть мнение, что ежедневные отчеты о проделанной работе пошли от японской школы менеджмента. Говорят, первые письменные ежедневные отчеты сотрудников стали применяться в японских корпорациях. Однако, увидев в одном из шедевров Хаяо Миядзаки приспособление для контроля посещения работников одной бани, я предполагаю, что в Японии такие отчеты культивируются еще со времен средневековья.
Но мы же не ретрограды... В настоящих Scram-командах, о которых я часто читаю в статьях, но крайне редко встречаю в жизни, проблемы учета рабочего времени, как правило, вообще нет. Это и понятно, поскольку все задачи, которые ставятся сотрудникам, имеют трудоемкость не более восьми часов, и перевод задачи JIRA в статус «выполнено» уже само по себе является отчетом о проделанной работе. И вообще, оценивать трудоемкость задач в часах скучно и неинтересно. Гораздо эффективней это делать в «футболках» или « помидорах ». Заставлять сотрудников вести логирование времени в этих условиях может только полный идиот. Так делают в правильных проектных командах, но, видимо, у меня другая карма.
Например, известие о том, что на программном проекте в интересах государственного заказчика успешно применяется Scram, я воспринимаю скорее как сигнал о том, что большая часть денег проекта уже освоена и проект надо вытягивать на энтузиазме.
Ходят слухи , что в таких случаях проектной команде очень может помочь ритуальный танец маори хака, который обычно исполняют новозеландские регбисты перед началом своих матчей. Не знаю, не пробовал. Но идея интересная.
Джефф Сазерленд в своей знаменитой
книге
связывает рождение методологии Scrum с проектом по разработке аналитической
системы «Страж» (Sentinel), выполняемым компанией Lockheed Martin
по заказу ФБР. Сазерленд пришел на проект, когда дата завершения была
просрочена на один год. Из выделенных из бюджета США 451 000 000$ было
потрачено почти 90% и реализовано только около половины требований. По
оценке тамошних экспертов, на завершение проекта требовалось еще
350 000 000$ и десять лет работы. При этом необходимость разработки системы
«Страж» была продиктована провалом проектов ФБР по созданию систем
«Автоматизированная поддержка следственных дел» (Automated Case Support,
ACS) и «Виртуальные следственные дела» (Virtual Case File, VCF), работа над
которыми стоимостью 170 000 000$ длилась без малого тринадцать лет. Вам эта
ситуация ничего не напоминает? Конечно, даже ребенку понятно, что поскольку
это случилось в стране с развитой, а не с развивающейся экономикой, эти
неприятности были вызваны исключительно тем, что люди просто не знали, как
правильно работать. Так в книжке и написано. Джефф всех научил. Scrum всех
спас.
Когда создавали программное обеспечение для лунной программы NASA, программисты видимо умели правильно работать. Интересно, за сколько спринтов они эту программулину написали? А потом то ли забыли, то ли разучились, то ли люди стали другие. Говорят, в то время информатика и разработка программного обеспечения ещё не были устоявшимися дисциплинами, и программисты учились на работе, на собственном практическом опыте. Может, они просто еще не знали перечень уважительных причин для срыва сроков и бюджета?
А я сколько раз не пытался применить Scrum, как-то все не получается. То ли проекты неправильные, то ли карма мешает. Почему-то на всех программных проектах в интересах государственных заказчиков, в которых я участвовал, мне ни разу не посчастливилось встретиться с менеджментом, который был бы действительно организован в соответствии с принципами Agile.
С терминологией Scrum на таких проектах встречался часто. В рамках применения ScrumBut ... И на тех же проектах, не раз, сталкивался с требованиями по ведению почасовой отчетности о проделанной работе.
Раздвоение личности
Когда большие не думают о маленьких, маленьким приходится жить как смогут. Рулить по своим законам. И это везде так… Чего вы так на меня смотрите? У вас как-то по-другому? Все в обойме. Все. Только каждый в своей.
Учитывая жизненный опыт, у меня сложилось двойственное отношение к учету трудозатрат на программных проектах. При этом так получилось, что это отношение не всегда совпадает с общепринятым. Поэтому, не отрицая положительных и негативных сторон таймтрекинга, я хотел бы остановиться на моментах, о которых обычно скромно умалчивают.
Это раздвоение личности в себе я заметил, с одной стороны, с точки зрения
исполнителя. Несмотря на первоначально негативное отношение к повременной
отчетности, через некоторое время выяснилось, что ежедневный учет
потраченного рабочего времени позволяет исключить со стороны руководства
вопросы из серии «Почему за целую неделю ничего не сделано?!». При разумном
подходе таймтрекинг в руках исполнителя становится инструментом адекватной
оценки результатов своего труда. Вы слышали, что можно зарабатывать больше
денег, делая ставку на понижение зарплаты? Вы не знаете, как это? Хотя я и
не трейдер, сейчас я вас научу плохому эффективному тайм-менеджменту.
На одной из моих предыдущих работ у меня сложились довольно доверительные отношения с одним из моих коллег. Несмотря на то, что мой товарищ был лучшим программистом среди нашего коллектива, он получал примерно такую же зарплату, как и другие разработчики нашей государственной « галеры». Какое-то время я не понимал, почему он не найдет более высокооплачиваемую работу. Однажды я не удержался и задал сакраментальный вопрос о дополнительных доходах. Оказалось, что мой коллега работает еще в четырех(!) компаниях. Несмотря на то, что это был одним из лучших программистов, которых мне посчастливилось встретить, его зарплата во всех компаниях была в полтора раза ниже зарплаты middle-программиста. Только вот задачи он решал в несколько раз быстрее. При этом его решения были более эффективные. Вы никогда не задумывались, сколько контрольных работ по математике для третьего класса сможет решить отличник-десятиклассник за один урок? Если он, конечно, настоящий отличник... Этот человек познакомил меня с миром фриланса и на практике показал, насколько результативно интеллект может монетизировать такой ресурс, как рабочее время.
На «диком поле» фриланса одним из « камней преткновения» для меня был вопрос оценки стоимости работ. И в итоге решение этой проблемы сводилось к оценке ожидаемой трудоемкости работ в часах с последующим перемножением этого времени на ожидаемую почасовую ставку. Однако это работало только в том случае, если перед началом работ было согласовано проектное решение , на основании которого можно было сделать такую оценку. При этом стоимость создания проектного решения также включалась в конечную сумму с учетом фактически затраченного времени.
Иногда на фрилансе я сталкивался с почасовой оплатой по факту. После того, как за ночь, проведенную в офисе, я взял деньги, как за два часа работы (по моему мнению, было бы неэтично заставлять платить заказчика за мою некомпетентность), с одним из клиентов у меня сложились доверительные отношения. Эти отношения выразились в том, что я не формулировал проектные решения, а просто решал задачи, которые ставил заказчик по факту, отчитываясь о затраченном времени на решение каждой из задач. При этом я указывал не фактически потраченное время, а то время, которое бы, с моей точки зрения, потратил бы на решение задачи специалист средней квалификации. Так я пришел к понятию нормочаса.
Однако такой подход в итоге не удовлетворил ни меня, ни заказчика. Для меня это было не выгодно тем, что для того, чтобы получить вознаграждение, я должен был разместить результат работы на сайте заказчика. Так сказать, сдать результат работы в «промышленную эксплуатацию». Но поскольку исходное требование, не будучи зафиксированным, обрастало все новыми и новыми подробностями, предсказать дату сдачи фактически было невозможно. Несмотря на то, что заказчик честно оплачивал выставленные нормочасы, такой непредсказуемый метод со временем стал меня, мягко говоря, нервировать. Со временем заказчику тоже перестал нравиться такой подход, поскольку оплата как простой, так и сложной работы рассчитывалась мной по одинаковой повременной ставке.
Позднее на программных проектах, где мне приходилось отчитываться за потраченное время, я подходил к формированию отчетов по принципам, которые были отшлифованы на фрилансовых заказах. При этом работодатель не оставался в накладе, поскольку моя деятельность становилась более ориентирована на результат. И, как правило, при таком подходе я всегда находился в числе лучших сотрудников. При этом в качестве бонуса я получал время, которое мог потратить по своему усмотрению. И что примечательно, положительные моменты персональной отчетности для исполнителя заметил не только я. Жаль вот только, что эти моменты не хотят замечать многие руководители. Почти в каждом описании вакансии обещано: «Работаем на результат». Но обещать - не значит жениться.
С точки зрения руководителя результаты применения таймтрекинга тоже оказались не совсем очевидными.
Во-первых, при формировании такой отчетности зачастую создается иллюзия бурной деятельности. У руководителя может сложиться ложное впечатление об истинном состоянии дел. В глазах менеджера процесс может подменить результат. Осознание реальности после такого наркоза может быть весьма болезненно. Особенно, если это осознание приходит на этапе проведения приемочных испытаний.
Во-вторых, я не раз сталкивался с распространенным ошибочным мнением руководства, что отчет о почасовых трудозатратах сотрудников позволяет оценить, какова степень выполнения задач.
Другой неожиданностью для руководителя может оказаться то, что собранные
материалы по таймтрекингу не оправдывают возлагаемых на них надежд в части
наведения порядка на проекте. Материалы отличные, все отчитались больше чем
по 40 часам в неделю - комар носа не подточит. Только порядка на проекте
больше не стало. Оказывается, получение отчетов о трудозатратах сотрудников
- это не то же самое, что эффективное использование этих отчетов для
управления проектом. Обычно статьи, посвященные анализу отчетов по
трудозатратам, содержат слова, что благодаря этим отчетам «можно
посмотреть» трудозатраты по каждому сотруднику, подразделению, виду работ и
т.п. Беда в том, что в этих статьях не говорится о том, что нужно сделать
для исправления ситуации на проекте после того, как посмотришь на отчеты по
трудозатратам. Каким образом преобразовать сведения, отраженные в отчетах,
в управляющее пинчище воздействие, адресованное конкретному сотруднику
проектной группы? А что делать, если, не дай Бог, выяснится, что сотрудник,
которому больше всего требуется это управляющее воздействие, - это
руководитель проекта? Поэтому многие руководители просмотром отчетов и
ограничиваются. Посмотрят на отчет, ну и считают, что этого достаточно.
Профессиональная деформация
В отчаянной битве за спокойную жизнь многие сотрудники забывают, за что именно они сражаются.
Кроме прочего, опыт фриланса принес мне профессиональную деформацию, от которой я никак не могу избавиться.
Не раз от коллег, всю жизнь проработавших в одной организации, при обсуждении возможного размера денежного вознаграждения я слышал фразу: «Я за такие деньги работать не буду». Обычно от этих же людей я часто слышал тезис: «Если бы мне платили нормальную зарплату, я бы и нормально работал».
Однако, когда Его Величество Случай предлагает этим сотрудникам работу, которую надо выполнить за хорошие деньги, они, как правило, оказываются не готовы к такому счастью.
Я так не могу. Профессиональная деформация фрилансера мешает. Поэтому при обсуждении размера денежного вознаграждения за работу я всегда стараюсь получить для себя ответы на целый ряд следующих вопросов.
-
Каково соотношение отвращения и удовлетворения, получаемых от выполнения этой работы?
-
Зависит ли решение только от исполнителя?
-
За какое время я смогу решить эту задачу?
-
Сколько времени требуется на решение этой задачи с точки зрения заказчика?
-
Требуется ли присутствие моего бренного тела в офисе работодателя? Как часто и как долго?
-
К какому моменту времени задача должна быть гарантированно решена? ( Deadline ?)
-
Что я получу, кроме денег в случае успешного решения задачи? Профит может быть выражен в получении новых знаний, опыта, постоянного клиента, полезных связей, строчки в резюме и разных других «борзых щенков».
Одним из ключевых моментов для принятия решения является ответ на вопрос: сколько моего времени нужно потратить, чтобы «поднять» эти деньги?
Вообще, по моим наблюдениям, именно способность к постановке и получению ответов на такие дополнительные вопросы во многом определяет успешность человека в этой жизни. Как вы думаете, операционныйдиректор компании « Treolan» тратит свое время на блог, посвященный секретам менеджмента, для того, чтобы подзаработать на контекстной рекламе? Или генеральный директор компании «Ланит-Терком» подрабатывает в Санкт-Петербургском государственном университете, потому что ему не хватает директорской зарплаты? И откуда они на это все берут время?
Антиподы
План, что и говорить, был превосходный: простой и ясный, лучше не придумать. Недостаток у него был только один: было совершенно неизвестно, как привести его в исполнение.
Иногда кажется, что разработчики и менеджеры живут в двух разных мирах, в которых действуют разные законы физики.
Мир менеджеров детерминирован и понятен. В нем царят предсказуемые законы и точные расчеты макромира. Как можно за несколько тысяч лет заранее предсказать точные координаты любой планеты, так и в мире менеджеров можно точно определить размер бюджета любого проекта - от постройки сарая до создания космодрома. Так же точно можно определить этапы, трудоемкость, квалификацию привлекаемого персонала и необходимые ресурсы.
Вот, например, сколько скрытых возможностей принесла пандемия. Нет худа без удаленки. Это ж можно три часа, которые тратил раньше на дорогу на работу и обратно, потратить на себя любимого. Главное - правильный план составить. Например, такой: каждый рабочий день один час тратить на фитнес, второй - на изучение Java, а третий - на совершенствование английского… Просто представить затруднительно, каким можно стать супервостребованным и супердорогим специалистом через полгода с таким планом… Аж дыхание останавливается от восторга, и сердце замирает в сладостном предвкушении…
Правда, спустя полгода выясняется, что вместо ожидаемого похудения набрал еще плюс пять кило, программа на Java гордо выводит два слова на экран терминала, а чтение книжки на английском застопорилось на четырнадцатой странице... По-моему, про это кто-то уже писал… Конечно, если план был составлен для себя, то все объяснимо. На то есть объективные причины, почему так произошло… Но если план не удался у кого-то другого (не у себя), то это тоже понятно. Это случилось не потому, что план плохой. Это потому, что этот исполнитель был бездельником, лентяем и лоботрясом. Скорее всего, типичным представителем мира разработчиков.
Ведь мир разработчиков хаотичен и непредсказуем. Здесь царит принцип неопределенности. Нарушения пространственно-временного континуума в порядке вещей. Наблюдаются прямые ассоциации с квантовой механикой. Например, замечено, что даже пассивное наблюдение за происходящими процессами мира разработки может существенно повлиять на результат измерения.
Представители обоих миров, как правило, слабо понимают мотивацию и логику друг друга, справедливо подозревая, что их антиподы немного «не от мира сего».
Теория относительности
Подержите руку минуту на горячей плите, и эта минута покажется вам часом. А час, проведенный с милой девушкой, покажется минутой.
Любой знает по собственному опыту, что время бывает очень разным, в зависимости от времени. Времени суток и возраста.
Одну и ту же работу, над которой можно тупить три часа в конце рабочего дня в пятницу, зачастую можно сделать за 20 минут утром в понедельник. Несмотря на то, что я по природе «жаворонок», почему-то мое животное наиболее эффективно занимается кодотерапией не в рабочее время, а в темное время суток, когда все нормальные люди уже спят.
У меня сложилась теория разного осознания времени в зависимости от возраста. Согласно этой теории, каждый человек ощущает продолжительность своего времени обратно пропорционально прожитой жизни. Например, для сорокалетнего человека 15 минут воспринимаются так же, как один час для десятилетнего или полчаса для двадцатилетнего.
Однако более старший сотрудник выигрывает у более молодого за счет применения готовых решений, накопленных за трудовую жизнь. В стандартной ситуации, как правило, молодой сотрудник проигрывает ветерану, поскольку ему нужно время на поиск и апробацию подходящего решения.
С возрастом начинаешь обращать внимание, что вещи, казавшиеся раньше незыблемыми, тоже подвержены изменениям. Например, замечаешь, как растут деревья. Или то, как незаметно, но неотвратимо меняется обстановка на проекте после принятия управленческих решений...
С другой стороны, в случае существенного изменения условий, когда требуется нестандартное решение, шансы на достижение успеха у молодых гораздо выше…
Некоторые эксперты вообще говорят о том, чтобы успешно выполнять все свои обязанности, необходимо не больше четырех часов в неделю!
В общем, из этого всего можно сделать два важных «вывода».
Первый - ощущать себя молодым выгодно и с экономической точки зрения.
Второй - чтобы составить адекватный план по разработке программного обеспечения, надо, чтобы сотрудники были одного возраста, одинаковой квалификации и все работали за полярным кругом, где день или ночь длятся по полгода.
Не партийная номенклатура
Если Вы уверены, что ваш проектный план в точности исполнится, то Вы - идиот. Если Вы не планируете работы на проекте, то Вы - самоубийца.
Если хочется добиться ожидаемых результатов на проекте, рано или поздно приходишь к мысли, что эти результаты надо научиться предсказывать. До начала работ. Заранее. Вопреки всем турбулентностям быстротекущей жизни.
Предсказание начинается с того, что появляется потребность оценить трудоемкость задач, которые предполагается решить в рамках проекта.
Поначалу я обычно использовал оценку, основанную на личном опыте. На небольших проектах это работало вполне сносно. Но со временем, погрузившись в трясину менеджмента, я заметил, что мои оценки носят слишком оптимистичный характер… И чем дальше я отходил от кода, тем больше оптимизма было в моих оценках… При этом калейдоскоп из использующихся в разных проектах языков программирования, паттернов и фреймворков не добавлял точности в мои оценки. Я пытался не отставать от программистов. Но чем крупнее проект, тем труднее было совмещать на нем две роли. Оказалось, приравнивать производительность сотрудников к своей - плохая идея.
На мой взгляд, если, будучи руководителем проекта, вы участвуете в собственном проекте как разработчик, независимо от вашей реальной квалификации, сотрудники проекта будут смотреть на вас как на самого сильного игрока в команде. И рано или поздно вы рискуете незаметно превратиться в главное ограничение этого проекта.
Я начал искать способы сделать планирование на проекте более объективным.
Первым шагом к формализации планирования стало осознание небольшой разницы между задачей и подзадачей в JIRA. Многие не видят этой разницы. На их взгляд, подзадача - это типа такая же задача, только маленькая. Почти то же самое. Я сам так думал. Раньше.
Сегодня я рассматриваю подзадачу как работу определенного типа, которая
может быть выполнена одним сотрудником от начала до завершения. При этом
подзадача не имеет смысла без реализации всей задачи целиком. Например,
проверка качества кода (code review) не имеет смысла, если, в конце концов
автоматизированная функция не будет использована в программе. С другой
стороны, при планировании под задачей я понимаю комлекс работ, в результате
выполнения которых для проекта будет нанесена непоправимая ощутимая польза,
достижение которой можно проверить и получить однозначный ответ, выполнена
эта задача или нет. Например, закрыть без замечаний прохождение тестового
задания по ПМИ. В идеале
– получить деньги за успешную реализацию этой функциональности.
Кроме того, при планировании работ я попытался применить лайфхак, оторый неприлично назойливо повторяют в своих книжках Генри Форд и Коносуке Мацусита . А именно - попытаться унифицировать задачи творческих сотрудников в магическом деле реализации программных проектов.
Поэтому я начал с того, что сформировал номенклатуры задач, выполнение которых, с моей точки зрения, раз за разом повторяется на моих программных проектах. Ключевой особенностью этих номенклатур являлось то, что для каждой такой нормативной задачи был определен ожидаемый результат. Номенклатуру аналитических задач на своих проектах я подробно препарировал в одной из своих статей. Кроме того, была создана номенклатура задач и для сотрудников, которые создают код своими руками. Номенклатура задач для программистов , рожденная воспаленным сознанием, травмированным менеджментом, у меня самого вызывает серьезные сомнения.
Дополнительным шагом стал учет ранга сложности задачи при ее планировании. Методика Story Points, призванная убирать противоречия в восприятии оценки разработчиком и менеджером, в моей голове породила больше вопросов, чем ответов. Прежде всего тем, что нивелировала разницу между разным уровнем квалификации, требуемой для решения разных задач. Поэтому при регистрации задач я ввел дополнительный параметр, который характеризовал уровень квалификации, требуемый для решения задачи.
Можно по-разному оценивать этот параметр. Как вариант, например, использовать стандартные уровни, как в зарплатном калькуляторе Habr : стажер (intern), младший (junior), средний (midle), старший (senior), ведущий (lead). Но на своих проектах я стал действовать иначе. В качестве этого параметра в JIRA регистрируется должность сотрудника, которой соответствует решаемая задача. При этом я использую не только должности сотрудников на проекте, но и должности, которые на моем проекте не предусмотрены, в том числе и должности, которые не предусмотрены штатным расписанием компании.
Перечень должностей и присущих этим должностям обязанностей можно подсмотреть в профессиональных стандартах . На программных проектах, на мой взгляд, наибольший интерес представляют следующие стандарты:
-
программист (разработка, отладка, проверка работоспособности, модификация компьютерного программного обеспечения);
-
архитектор программного обеспечения (проектирование, мониторинг и контроль архитектуры программного обеспечения);
-
аналитик (разработка, восстановление и сопровождение требований к программному обеспечению, продукту, средству, программно-аппаратному комплексу, автоматизированной информационной системе или автоматизированной системе управления на протяжении их жизненного цикла);
-
cпециалист по тестированию (оценка качества разрабатываемого программного обеспечения путем проверки соответствия программного продукта заявленным требованиям);
-
системный администратор (обеспечение требуемого качественного бесперебойного режима работы инфокоммуникационной системы);
-
cпециалист по защите информации (обеспечение безопасности информации в автоматизированных системах);
-
руководитель разработки программного обеспечения (управление процессами разработки, отладки, проверки работоспособности и модификации компьютерного программного обеспечения, и управлению ресурсами).
Со временем оценка занятости конкретных сотрудников, построенная на основании данного параметра, может принести вам немало удивительных открытий.
Вдруг, например, может выясниться, что старший программист большую часть своего времени тратит на элементарные задачи, связанные с настройкой стендов, больше подходящие для начинающего сисадмина. Ведущий аналитик погряз в ручном регрессионном тестировании... Архитектор проекта с увлечением решает инциденты... А недавно нанятый студент самостоятельно реализует сложные интеграционные решения или согласовывает технические задания с заказчиком. Всё это может быть не так и плохо... В небольших количествах это может быть хорошим лекарством от карьерного головокружения и должностного склероза... Все зависит от той доли рабочего времени, которое тратит сотрудник на выполнение задач, которые не соответствуют его должностному положению...
С другой стороны, накопленная статистика открывает потенциальную возможность по оценке качества управления проектом. Насколько реальное назначение задач сотрудникам соответствует их текущей квалификации? Какую долю своего рабочего времени работник тратит на выполнение задач, не соответствующих его рангу или квалификации? Есть ли динамика изменения этих показателей во времени? Какие мероприятия были спланированы для улучшения этих показателей?
На основании этой статистики можно обосновать предложения для топ-менеджмента по изменению штатного состава проектной группы. Можно подготовить объективные данные для проведения аттестации с целью пересмотра должностей и уровня зарплаты отдельных сотрудников. Можно выстроить прозрачную карьерную лестницу для мотивации персонала. Можно принять обоснованное решение о привлечении специалистов на аутсорсинг. Много чего интересного можно замутить. Если, конечно, спонсоров проекта действительно интересует эффективность проектной группы...
Но не буду забегать вперед. MoneyDev заслуживает отдельной статьи.
Анти-героин
Часто неспособность выполнить задачу за небольшой обозримый кусок времени свидетельствует не столько о трудоемкости задачи, сколько о слабом понимании того, что конкретно надо сделать.
Когда я только начинал руководить проектными командами, я внутренне в тайне гордился своей способностью поднимать людей «в атаку», чтобы «допилить» горящий проект после окончания рабочего дня, в выходные и по ночам. Но со временем здравый смысл стал постепенно побеждать безудержный энтузиазм. Я узнал о существовании уровней зрелости управления , а также то, что начальный уровень зачастую называют уровнем героев, поскольку проект выживает только за счет постоянного совершения «подвигов». Сегодня для меня уровень зрелости руководителя гораздо лучше характеризует его способность достигать целей проекта без организации авралов.
Одним из наиболее распространенных советов, которые можно найти для решения проблемы оценки трудоемкости задач, является декомпозиция крупных задач на более мелкие элементы, каждый длительностью не более 4-8 рабочих часов. Это, конечно, правильно, поскольку тогда каждый рабочий день на проекте должен быть результативным.
С другой стороны, хотелось, чтобы в ходе выполнения задачи на разработку достигался результат, значимый с точки зрения заказчика. Или результат, который можно протестировать. Получение такого результата не всегда достижимо за 8 рабочих часов.
В поисках ответа на эти вопросы и их решения я соорудил калькуляторы для расчета трудоемкости задач аналитиков и программистов, которые я рекомендую применять для снижения уровня героизма на проекте.
В основу этого инструмента лег так называемый инженерный метод оценки трудоемкости проекта PERT (Program / Project Evaluation and Review Technique), который был разработан еще в 1958 году консалтинговой фирмой «Буз, Ален и Гамильтон» ( Booz Allen Hamilton ) совместно с корпорацией Lockheed Martin (кстати, той самой, которая потом исполняла контракт с ФБР) по заказу Подразделения специальных проектов ВМС США для проекта создания ракетной системы « Поларис » ( Polaris ).
Рекомендуемый PM BOK метод определения стоимости по трем точкам является не чем иным, как вырожденным методом PERT. Видимо, чтобы не пугать менеджеров математическими операциями, выходящими за курс арифметики начальных классов средней школы, подход, описанный в PM BOK, не учитывает резерв времени, основанный на среднеквадратичном отклонении (девиации) суммарной трудоемкости. Это, конечно, мелочь. Однако эта мелочь может достигать примерно 10-15% от общей трудоемкости задач. Как влияют десять процентов недооценки на проект, помогает оценить модель дорожного движения. Представьте, что машинки – это задачи. Сравните общую пропускную способность при отсутствии машин с боковой дороги и в случае, когда с боковой дороги поступает 10% трафика. Ничего не напоминает?
Как правило, метод PERT рекомендуется применять для верхнеуровневой оценки иерархической структуры работ проекта (Work Breakdown Structure, WBS), где каждая работа не исключает в перспективе исполнение целым коллективом сотрудников (в моей парадигме это несколько задач в JIRA). Мне же был нужен инструмент для оценки трудозатрат конкретного сотрудника на получение от него измеримой пользы на программном проекте.
В случае если удается планировать задачи трудоемкостью не более восьми часов, то эти калькуляторы в принципе не нужны. Но если на планируемую задачу предполагается потратить больше времени, я прошу аналитика, ответсвенного за реализацию требований, чтобы задача для исполнителя была спланирована с помощью калькулятора. Фактически это средство фиксации диалога между автором задачи и исполнителем при дроблении задачи на более мелкие составные части. Замечено, что в течение 15-20 минут можно в ходе спокойного разговора сформировать детализированный план на 2-3 рабочих дня исполнителя. В ходе обсуждения необходимо сформировать перечень работ, в котором сам исполнитель определяет минимальную, оптимальную и максимальную трудоемкость каждой из работ. При этом необходимо конкретизировать предопределенные формулировки, а также возможно изменить порядок следования работ.
Полученный результат можно зафиксировать в JIRA двумя способами.
Первый, менее трудоемкий для регистрации: в случае если задачу решает один сотрудник, можно скопировать полученный результат в описание задачи JIRA и назначить общую первоначальную оценку ( time estimate ) как общую трудоемкость, рассчитанную с помощью калькулятора.
При этом, если вы хотите контролировать ход выполнения работ, ответственный исполнитель по мере выполнения задачи должен фиксировать свои трудозатраты.
Второй подход, более хлопотный для регистрации, строится на учете отдельных работ как подзадач. При этом трудоемкость, выделенная в резерв, регистрируется как трудоемкость основной задачи. Подзадачи могут назначаться разным исполнителям. Ограничения JIRA не позволят закрыть основную задачу, перед этим не завершив все подзадачи.
Именно второй подход позволяет собрать статистику трудозатрат по выполнению работ разного типа. Когда мы обсуждаем с моими коллегами-менеджерами проблемы этой статьи, я часто слышу от них возглас: « Ха! Да разработчики завысят трудоемкость! Лапшу на уши навешают! Да и от ошибок никто не застрахован». Конечно, это так, кто бы спорил. Для каждого отдельного случая это вполне допустимо. Но если у вас есть статистика по типам работ, на ее фоне ошибки планирования проявляются все контрастнее и становятся индикаторами для выяснения причин резких отклонений в оценке однотипных работ.
Кроме того, в случае если у меня нет возможности оплатить более высокую эффективность работника, честно говоря, я смотрю сквозь пальцы на то, что лучшие сотрудники проекта делают свою работу несколько быстрее, чем было запланировано изначально. Я вообще приветствую, если мои коллеги, успевая вовремя выполнять свою работу на проекте, находят время для применения своих талантов на фрилансе. Обычно именно такие сотрудники, кроме того, что работают быстрее и качественнее, приносят на проект новые технологии и решения, апробированные на других проектах.
Меня же гораздо больше волнуют те, кто по классификации
Джека Уэлча
называются C-players. Те, на
кого рано или поздно будет равняться вся проектная группа. На главное
огорчение ограничение на проекте. Точнее, на проблемы того единственного,
который определяет нижнюю границу производительности на проекте. Того, кто
служит примером того, как не нужно работать. По моему твердому убеждению,
для успешности проекта гораздо важнее не подгонять лидеров, а помочь решить
проблемы аутсайдеров.
Запуская этот инструмент в работу своей проектной команды, я надеялся с его помощью уйти от такого непопулярного таймтрекинга. Мне казалось, правильно декомпозированные и оцененные задачи сделают процесс разработки программного обеспечения похожим на процесс обслуживания автомобиля в автосервисе. Аналитик, ответственный за реализацию пула требований, формирует проектное решение , согласовывает его с заказчиком, после чего формирует перечень задач для разработчиков. Примерно так же, как вы вместе с мастером составляете перечень работ в автосервисе. Дальше рабочие уже просто выполняют предопределенные работы, не заботясь о таймтрекинге. Просто «чекают» выполненные подзадачи.
Я ошибался. Оказывается, что прогноз трудоемкости задачи на проекте - не полетное задание для ракеты, которая согласно этому заданию прилетит в назначенное место в точно рассчитанный срок.
После того, как через некоторое время в JIRA накопилось достаточное количество выполненных задач с «научно-обоснованными» оценками трудоемкости, я заметил, что дебит рабочего времени катастрофически не сходится с запланированным кредитом. Для того, чтобы разобраться в причинах неадекватной оценки, скрепя сердцем, я принял решение о необходимости ведения таймтрекинга на проекте.
Если программист способен писать комментарии к программному коду, то, скорее всего, его не затруднит написать несколько строчек о том, чем он занимался в течение рабочего дня. Если программист не способен писать комментарии, то нужен ли такой программист в проектной команде?
Не забудьте про овраги
Статья 59. Доклад старшему начальнику и информирование соседей об обстановке составляют важнейшую обязанность при выполнении поставленной задачи.
Но оказалось, чтобы понимать, что творится на проекте, недостаточно просто отмечать затраченное время по задачам.
Я всегда старался минимизировать количество данных, необходимых для первичного учета. И поэтому, когда я увидел на форме учета рабочего времени много, на первый взгляд, ненужных полей, я обратился к нашему главному «жироводу» с просьбой убрать эти поля с глаз долой.
Однако наш специалист сообщил мне, что убрать группу полей об уточнении оставшегося времени не получается. Ну никак. Я смирился, никак не используя этот функционал. И, как оказалось, зря.
Случаи существенного превышения реально регистрируемых трудозатрат по отношению к запланированной трудоемкости напомнили мне об одном давнем происшествии. Это случилось, когда я проходил службу в рядах Вооруженных сил. Однажды прекрасным летним воскресным утром, сразу после завтрака, нашему взводу была поставлена задача срочно выкопать траншею длиной метров пятьдесят и глубиной два метра. Стояла прекрасная погода, почва средней полосы России не предвещала ничего необычного. Личный состав был мотивирован предстоящим увольнением из расположения части, и даже кроту было понятно, что взвод здоровых розовощеких молодых парней выполнит эту задачу максимум до обеда. Часа за четыре. Никто не ожидал в полуметре под зеленой травкой обнаружить свалку строительного мусора с небольшим озерцом застывшего бетона... Это выяснилось буквально через полчаса после начала работ. Чтобы прорубиться через эту свалку на заданную глубину в требуемом направлении, потребовалось еще четыре дня работ без передыха. При этом вышестоящее начальство первое время недоумевало от несоответствия сроков их ожиданиям и вместо того, чтобы разобраться в причинах задержки, «прессовало» личный состав через младших командиров. От такой «адекватной» оценки начальства работа выполнялась еще медленнее.
Ближе всех к решению задачи находится ее непосредственный исполнитель. Именно он точнее всех на текущий момент может сказать, сколько еще времени нужно для окончания работы. Введение в проектную практику регулярного со стороны исполнителя уточнения времени, необходимого для завершения работы, фактически исключило потребность выводить задачу в статус «Ожидание» по причинам <требуется уточнение планируемой трудоемкости> и <требуется уточнение сроков выполнения>, о необходимости которых я писал в одной из своих статей ранее.
Вместе с тем превышение ожидаемой трудоемкости – это главный флаг, который «кричит» о надвигающейся проблеме. Причем далеко не всегда это проблема исполнителя. Может, при решении задачи он натолкнулся на «озерцо застывшего бетона»?
Проклятие Паркинсона
Работа стремится занять все время, отпущенное на нее.
Есть такая напасть на проектах... Закон Паркинсона называется. Сводится к тому, что сколько исполнителя сроками не корми, он все сделает в последний момент и с ошибками. В общем, закон этот говорит о том, что гуманное отношение к исполнителю противопоказано. Вредит оно проекту. С 1997 года ходят упорные слухи, что Эльяху Голдрат придумал от этой напасти снадобье. Метод критической цепи называется. Если совсем коротко, терапия состоит в том, что при планировании после оценки задач нужно просто волевым решением трудоемкость всех взаимоувязанных для достижения одной цели работ сократить в два раза, а получившийся профит времени вынести в общий резерв времени. Методика, конечно, отличная. Однако у меня есть одна маленькая несостыковка. Как потом ребятам объяснить, каким местом думал менеджер, когда решил запланированную трудоемкость задач в два раза ополовинить?
В некоторых публикациях, посвященных методу критической цепи, противопоставляют этот подход методу PERT. Однако во время написания этой статьи мне пришла идея, как скрестить ежа с ужом. Мысль, которую я планирую в ближайшее время апробировать на своей команде.
Идея заключается в том, что при планировании одной большой задачи трудоемкость каждой отдельной подзадачи определять как минимальное время, необходимое для решения такой подзадачи. Вместе с тем разность между общей оценкой задачи по методу PERT и суммой минимальных трудозатрат на подзадачи фиксировать как общий резерв задачи. При этом дельта сроков выполнения подзадач и срока основной задачи должна быть не меньше общего резерва задачи. Или не меньше одного рабочего дня, если такой резерв менее восьми часов.
А коллегам можно пояснить, что если они не справятся в рамках запланированной трудоемкости, то могут уточнить текущее состояние дел, безболезненно указав, сколько еще времени нужно для завершения работы.
Посмотрим, что получится...
Учет черных дыр и белых пятен
Что измеряется, то и улучшается.
Когда мы только завели JIRA для проектной группы, то регистрировали только самые важные задачи, а на мелочевку не заморачивались. Однако такой подход быстро себя исчерпал. Как оказалось, не всегда удавалось определить степень важности проблемы на этапе ее возникновения. Не раз и не два оказывалось, что на первый взгляд незначительное требование, которое изначально не регистрировалось в JIRA, перерастало потом в лавину проблем, требующих решения.
С введением таймтрекинга разрыв регистрируемых данных с объективной реальностью стал заметен еще больше. На мой взгляд, введение таймтрекинга в условиях, когда в системе управления проектами регистрируются не все работы, сродни попытке носить воду с помощью сита.
В связи с этим на проекте постепенно был введен ряд правил, которых придерживаются все сотрудники команды.
Во-первых, любая задача, зарегистрированная в JIRA, должна быть связана с требованиями, в интересах выполнения которых она была инициирована. О порядке регистрации требований подробно было рассказано ранее.
Во-вторых, все работы на проекте выполняются только в рамках задач, зарегистрированных в JIRA. Нет задачи – нет работы. Никто не вправе спрашивать результаты или отчитываться по работам, если эта работа не зарегистрирована в JIRA в форме задачи.
В-третьих, каждая задача или подзадача в JIRA всегда от начала до конца выполняется только одним исполнителем. Если в случае необходимости задача была передана другому сотруднику для завершения, то все трудозатраты, которые были выполнены предыдущим исполнителем, считаются израсходованными вхолостую. В случае если часть работы по реализации задачи все-таки можно считать выполненной, а сотрудник по объективным причинам не смог довести дело до конца, задача закрывается с регистрацией достигнутого результата, а для нового исполнителя инициируется новая задача с учетом предварительно выполненных работ.
В-четвертых, по отношению к каждой задаче (подзадаче) различают две главные роли: Автор и Исполнитель. Исполнитель отвечает за свою задачу, только если она находится в статусе <В работе>. Если задача находится в статусах <Оценка>, <В ожидании> или <Контроль>, то значит, она находится в зоне ответственности Автора задачи. При этом Авторы регистрируют свои трудозатраты по созданию и сопровождению задач Исполнителей в рамках своих задач. Например, трудозатраты по созданию и согласованию структуры работ по исполнению проектного решения фиксируются в рамках задачи по созданию этого проектного решения. С другой стороны, трудозатраты на проверку выполненной работы могут фиксироваться Автором в соответствующей подзадаче, назначенной на себя.
Так же оказалось, что есть целый пласт деятельности, который с одной
стороны, сложно запланировать заранее, а с другой , который может занимать
значительную часть рабочего времени. Это совещания и разнообразные
согласования разных вопросов, которые сопровождают любой проект.
Действительно, как запланировать время, если у меня, как у руководителя
проекта, может уйти пару часов, чтобы подготовиться к совещанию, которое у
других сотрудников займет 15 минут? Да и после совещания один сразу начнет
выполнять свои задачи, а другой еще час потратит на формулировку
предложений и замечаний по результатам этого совещания? Для решения учета
этого времени на проекте после нескольких экскрементов экспериментов пришли
к следующей рабочей схеме. В JIRA раз в неделю регистрируется одна задача
по проведению совещаний. Все сотрудники, находящиеся «в строю», сами
регистрируют подзадачи на себя в рамках этой задачи и в течение недели по
факту списывают время, затраченное на проведение совещаний и согласование
разных вопросов между собой.
Кроме того, на нашем проекте есть особый приоритет для запланированных задач - «если есть время». Данный статус обычно назначается «долгоиграющим» работам по рефакторингу нашего программного обеспечения и задачам, связанным с повышением квалификации сотрудников.
Сроки выполнения таких задач можно безболезненно переносить в случае внезапного увеличения количества заявок, требующих срочного решения. Поэтому время, зарезервированное при планировании для этих задач, может служить дополнительным способом для снижения вероятности незапланированной работы после окончания рабочего дня.
Правила перехода
Итак, чего не должно быть, знает каждый.
Что должно быть - знают все.
Перехода не знает никто.
Есть много хороших и правильных книжек, в которых скрупулезно описано, какими характеристиками должна отличаться гаражная мастерская от автосервиса дилера Toyota. Однако дорожная карта от гаража до успешного предприятия у каждого своя. По моему выстраданному убеждению, если бы Apple, Hewlett-Packard, Amazon или Google начинали свои проекты в стремлении точно соответствовать рекомендациям PM BOK или CMMI-DEV , мы бы никогда не услышали названия этих компаний.
Оглядываясь назад и анализируя свой опыт, я перестал удивляться тому, что не существует универсальных решений для всех случаев жизни. И я уверен, что таймтрекинг - это только один из этапов роста проектной команды, который надо пройти, чтобы, накопив опыт, оставить его в прошлом. Если у команды есть обоснованные нормативы, таймтрекинг излишен. Нормативы – это не когда на проекте есть перечень нормированных работ. Нормативы, на мой взгляд, это когда к этому перечню привязана зарплата сотрудников. Если эту привязку не сделает руководство, рано или поздно лучшие сотрудники сделают это сами. Ну, вы сами знаете как... Если не смогут найти работу в другой компании.
“Истинная производительность всегда дает максимальные результаты при минимальных усилиях; напряжение, наоборот, дает довольно крупные результаты при при усилиях ненормально тяжелых. На принципе напряжения основана поштучная оплата. Наоборот, нормирование выработки и премиальная система основаны на принципе производительности. Поштучная оплата – это возвращение к уровню дикаря; нормирование выработки – это шаг к будущему.”
Сегодня я вместе со своей командой пытаюсь найти наш путь к состоянию, когда максимальные результаты достигаются при минимальных усилиях. Всем известно: чтобы система работала эффективно, цели системы должны совпадать с целями элементов ее составляющих. Поэтому я пытаюсь выстроить правила работы таким образом, чтобы каждый сотрудник мог сформировать свою индивидуальную траекторию личного успеха в русле наших проектов. Это довольно простые правила.
Многие руководители любят, когда все сотрудники работают в одном месте. В офисе. Я тоже отношу себя к числу таких руководителей. Однако, несмотря на то, что я предпочитаю общаться со своими коллегами очно, московский трафик привил стойкое отвращение к посещению офиса. Пандемия помогла проектной группе перейти на почти полностью удаленный режим работы. Правила нашей удаленки подразумевают, что с 9.00 до 18.00 сотрудники должны быть готовы:
-
отвечать на телефонные звонки коллег (в случае, если в данный момент ответить не получается тот, кому звонили, должен перезвонить при первой возможности);
-
в течение 30 минут быть возле своего компьютера в готовности при необходимости продемонстрировать экран монитора;
-
при необходимости в течение двух часов прибыть в офис (за последние три года такой необходимости не возникло ни разу).
Почему 30 минут, для того чтобы добраться до компа? Примерно столько времени нужно, чтобы спокойно пообедать в столовой в офисе и вернуться на рабочее место. Или закончить тренировку в нашем спортзале или на площадке возле дома. Сходить в магазин. Встретить ребенка из детского сада. Для этого не надо отпрашиваться. Если нужно больше времени для решения личных вопросов в рабочее время, достаточно просто согласовать этот вопрос с руководителем проекта и с авторами задач. Служебные вопросы должны решаться вовремя, а личные немедленно.
Раз в неделю проектная группа собирается в офисе, чтобы скоординировать планы. В случае подготовки к предварительным испытаниям количество встреч в офисе может быть увеличено.
Мне, все равно, в какое время суток выполняются задачи на проекте. Главное, чтобы эти задачи были реализованы в запланированные сроки.
Также я жду от своих коллег того, что до проведения очередного ежедневного on-line совещания, в JIRA оказались данные по результатам, достигнутым по назначенным задачам за прошедшие сутки, с уточнением того, сколько времени осталось до их завершения.
При этом я не призываю своих коллег на трудовые подвиги.
Наоборот, если сотрудник тратит больше времени на решение запланированных задач, я не требую от него работать внеурочно. Я прошу его просто своевременно отмечать трудозатраты и уточнять требуемое время для завершения этих задач, чтобы я мог заблаговременно согласовать перенос сроков их выполнения. И еще я прошу, чтобы в отчетах о потраченном времени отражался не процесс, а достигнутый результат. Например, сотрудник потратил три часа на изучение новой технологии, но ничего не понял, и у него ничего не получилось. Как может быть отражен результат такой работы? На мой взгляд, результат в этом случае может быть зафиксирован в виде перечня возникших вопросов и скринов возникших ошибок, к решению которых можно привлечь более опытных коллег.
Продолжение следует
Что в «сухом» остатке? Что изменилось на проекте после введения таймтрекинга?
Прежде всего, пришлось осознать несколько объективных фактов:
-
более чем в четыре раза может отличаться производительность сотрудников с одинаковой зарплатой;
-
трудозатраты на реализацию дополнительных требований могут составлять более 30% бюджета проекта;
-
более 50% трудозатрат не учитываются при финансовом планировании.
При этом альтруизм в пользу заказчика, как правило, не приводил к положительному эффекту. Неучтенные при планировании, но фактически выполненные в интересах заказчика работы, возвращаются продолжительным эхом новых инцидентов и новых претензий. Которые надо решать уже в рамках гарантийных обязательств.
В случае, если на проекте возникают проблемы, первое желание настоящего менеджера – найти и покарать виновного в этом безобразии. Но изучение статистики таймтрекинга может принести неожиданные озарения и постепенное угасание этого, такого естественного, порыва.
Оказывается, для предотвращения проблем, гораздо эффективней не искать виновных, а создать условия, чтобы быть лодырем на проекте было неуютно. Для этого, например, сформировать прозрачные правила оценки результатов не только команды, но и каждого сотрудника.
Совещания с вышестоящим руководством приобрели более конструктивный характер. Например, когда мне говорят, что по политическим и стратегическим соображениям проектной команде надо пробежать стометровку за три секунды, у меня есть что на это ответить. И что предложить взамен.
Хотя иногда я прошу коллег сделать кое-какие срочные работы на выходных, сотрудники проектной группы перестали жаловаться на нехватку рабочего времени.
Отчасти это произошло потому, что сведения по трудозатратам стали использоваться для превентивного выявления и предотвращения угроз срыва задач на проекте, за счет своевременного перераспределения ресурсов и пересогласования сроков с заказчиком. Для того чтобы визуализировать эти риски, своевременно принимать решения, оценивать индивидуальную результативность и финансовую отдачу на нашем проекте было реализовано несколько доморощенных инструментов, о которых я надеюсь рассказать в следующих статьях.