Рабочее время: кошелек или жизнь?
Проблемы учета рабочего времени обсуждались не раз и не два. При этом мнение о необходимости таймтрекинга разделяет сотрудников на два противоположных лагеря. Как правило, исполнители всячески осуждают и указывают на неэффективность проектов, в которых необходимо вести учет рабочего времени и ежедневно отчитываться о проделанной работе. Напротив, многие правильные руководители приводят множество доводов в пользу таймтрекинга своих сотрудников. Это противоречие порой вызывает у меня приступы сильной головной боли, которую я попытался унять написанием этой статьи в блог ЛАНИТ. Есть такое лекарство — мышление письмом…
По мотивам
Мелочи жизни
С возрастом до меня постепенно стала доходить важность небольших отличий. Вот, например, два человека. Они почти одинаковы. Руки, ноги, туловище, голова… Есть, правда, небольшие конструктивные особенности, потому что один человек — это женщина, а другой– мужчина… А красивая женщина от некрасивой по комплектации вообще ничем не отличается. По внешним признакам вообще не отличишь умного от глупого, труса от храбреца, бедного от богатого, доброго от злого, подонка от человека чести.
По мотивам
Когда-то я читал, что синоби многолетними тренировками превращали свое тело в живое оружие. Детей подвергали жестоким и весьма болезненным процедурам с целью добиться свободного расчленения суставов. В фехтовании расчленение сустава позволяло на полтора-два сантиметра удлинить руку при ударе. Раньше мне казалось, что это несоразмерная плата за годы изнурительных тренировок. Однако с приобретением жизненного опыта я осознал разницу в ударах холодным оружием, которые наносятся в миллиметре от горла или на два сантиметра глубже. Постепенно жизнь изменила мое отношение к мелочам.
Заметить мелочи бывает непросто. Парадокс, но для того, чтобы заметить небольшую разницу, надо просмотреть много материала. Наверное, поэтому впереди будет много слов об общеизвестных истинах. Не дайте себя обмануть. Следите за движениями рук…
Источник
Однако если у вас на проекте и без ведения учета рабочего времени все хорошо, не стоит тратить свое время и забивать себе голову проблемами этой статьи. От тех, кто все-таки решится прочитать, надеюсь получить конструктивную критику.
Про патроны
— Товарищ замполит! Патроны кончились!
— Но ты же коммунист!
И пулемет застрочил с новой силой…Из проектных былей
Однажды я присутствовал на встрече, посвященной обмену опытом использования 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… (Не путать со ScrumBan.) И на тех же проектах, не раз, сталкивался с требованиями по ведению почасовой отчетности о проделанной работе.
Раздвоение личности
Когда большие не думают о маленьких, маленьким приходится жить как смогут. Рулить по своим законам. И это везде так… Чего вы так на меня смотрите? У вас как-то по-другому? Все в обойме. Все. Только каждый в своей.
Директор кладбища. 12
Источник
Учитывая жизненный опыт, у меня сложилось двойственное отношение к учету трудозатрат на программных проектах. При этом так получилось, что это отношение не всегда совпадает с общепринятым. Поэтому, не отрицая положительных и негативных сторон таймтрекинга, я хотел бы остановиться на моментах, о которых обычно скромно умалчивают.
Это раздвоение личности в себе я заметил, с одной стороны, с точки зрения исполнителя. Несмотря на первоначально негативное отношение к повременной отчетности, через некоторое время выяснилось, что ежедневный учет потраченного рабочего времени позволяет исключить со стороны руководства вопросы из серии «Почему за целую неделю ничего не сделано?!». При разумном подходе таймтрекинг в руках исполнителя становится инструментом адекватной оценки результатов своего труда. Вы слышали, что можно зарабатывать больше денег, делая ставку на понижение зарплаты? Вы не знаете, как это? Хотя я и не трейдер, сейчас я вас научу эффективному тайм-менеджменту.
Источник
На одной из моих предыдущих работ у меня сложились довольно доверительные отношения с одним из моих коллег. Несмотря на то, что мой товарищ был лучшим программистом среди нашего коллектива, он получал примерно такую же зарплату, как и другие разработчики нашей государственной «галеры». Какое-то время я не понимал, почему он не найдет более высокооплачиваемую работу. Однажды я не удержался и задал сакраментальный вопрос о дополнительных доходах. Оказалось, что мой коллега работает еще в четырех (!) компаниях. Несмотря на то, что это был одним из лучших программистов, которых мне посчастливилось встретить, его зарплата во всех компаниях была в полтора раза ниже зарплаты middle-программиста. Только вот задачи он решал в несколько раз быстрее. При этом его решения были более эффективные. Вы никогда не задумывались, сколько контрольных работ по математике для третьего класса сможет решить отличник-десятиклассник за один урок? Если он, конечно, настоящий отличник… Этот человек познакомил меня с миром фриланса и на практике показал, насколько результативно интеллект может монетизировать такой ресурс, как рабочее время.
На «диком поле» фриланса одним из «камней преткновения» для меня был вопрос оценки стоимости работ. И в итоге решение этой проблемы сводилось к оценке ожидаемой трудоемкости работ в часах с последующим перемножением этого времени на ожидаемую почасовую ставку. Однако это работало только в том случае, если перед началом работ было согласовано проектное решение, на основании которого можно было сделать такую оценку. При этом стоимость создания проектного решения также включалась в конечную сумму с учетом фактически затраченного времени.
Иногда на фрилансе я сталкивался с почасовой оплатой по факту. После того, как за ночь, проведенную в офисе, я взял деньги, как за два часа работы (по моему мнению, было бы неэтично заставлять платить заказчика за мою некомпетентность), с одним из клиентов у меня сложились доверительные отношения. Эти отношения выразились в том, что я не формулировал проектные решения, а просто решал задачи, которые ставил заказчик по факту, отчитываясь о затраченном времени на решение каждой из задач. При этом я указывал не фактически потраченное время, а то время, которое бы, с моей точки зрения, потратил бы на решение задачи специалист средней квалификации. Так я пришел к понятию нормочаса.
По мотивам
Однако такой подход в итоге не удовлетворил ни меня, ни заказчика. Для меня это было не выгодно тем, что для того, чтобы получить вознаграждение, я должен был разместить результат работы на сайте заказчика. Так сказать, сдать результат работы в «промышленную эксплуатацию». Но поскольку исходное требование, не будучи зафиксированным, обрастало все новыми и новыми подробностями, предсказать дату сдачи фактически было невозможно. Несмотря на то, что заказчик честно оплачивал выставленные нормочасы, такой непредсказуемый метод со временем стал меня, мягко говоря, нервировать. Со временем заказчику тоже перестал нравиться такой подход, поскольку оплата как простой, так и сложной работы рассчитывалась мной по одинаковой повременной ставке.
Позднее на программных проектах, где мне приходилось отчитываться за потраченное время, я подходил к формированию отчетов по принципам, которые были отшлифованы на фрилансовых заказах. При этом работодатель не оставался в накладе, поскольку моя деятельность становилась более ориентирована на результат. И, как правило, при таком подходе я всегда находился в числе лучших сотрудников. При этом в качестве бонуса я получал время, которое мог потратить по своему усмотрению. И что примечательно, положительные моменты персональной отчетности для исполнителя заметил не только я. Жаль вот только, что эти моменты не хотят замечать многие руководители. Почти в каждом описании вакансии обещано: «Работаем на результат». Но обещать — не значит жениться.
По мотивам
С точки зрения руководителя результаты применения таймтрекинга тоже оказались не совсем очевидными.
Во-первых, при формировании такой отчетности зачастую создается иллюзия бурной деятельности. У руководителя может сложиться ложное впечатление об истинном состоянии дел. В глазах менеджера процесс может подменить результат. Осознание реальности после такого наркоза может быть весьма болезненно. Особенно, если это осознание приходит на этапе проведения приемочных испытаний.
Во-вторых, я не раз сталкивался с распространенным ошибочным мнением руководства, что отчет о почасовых трудозатратах сотрудников позволяет оценить, какова степень выполнения задач.
Другой неожиданностью для руководителя может оказаться то, что собранные материалы по таймтрекингу не оправдывают возлагаемых на них надежд в части наведения порядка на проекте. Материалы отличные, все отчитались больше чем по 40 часам в неделю — комар носа не подточит. Только порядка на проекте больше не стало. Оказывается, получение отчетов о трудозатратах сотрудников — это не то же самое, что эффективное использование этих отчетов для управления проектом. Обычно статьи, посвященные анализу отчетов по трудозатратам, содержат слова, что благодаря этим отчетам «можно посмотреть» трудозатраты по каждому сотруднику, подразделению, виду работ и т.п. Беда в том, что в этих статьях не говорится о том, что нужно сделать для исправления ситуации на проекте после того, как посмотришь на отчеты по трудозатратам. Каким образом преобразовать сведения, отраженные в отчетах, в управляющее пинчище воздействие, адресованное конкретному сотруднику проектной группы? А что делать, если, не дай Бог, выяснится, что сотрудник, которому больше всего требуется это управляющее воздействие, — это руководитель проекта? Поэтому многие руководители просмотром отчетов и ограничиваются. Посмотрят на отчет, ну и считают, что этого достаточно.
Профессиональная деформация
В отчаянной битве за спокойную жизнь многие сотрудники забывают, за что именно они сражаются.
Личное наблюдение
Кроме прочего, опыт фриланса принес мне профессиональную деформацию, от которой я никак не могу избавиться.
Не раз от коллег, всю жизнь проработавших в одной организации, при обсуждении возможного размера денежного вознаграждения я слышал фразу: «Я за такие деньги работать не буду». Обычно от этих же людей я часто слышал тезис: «Если бы мне платили нормальную зарплату, я бы и нормально работал».
Однако, когда Его Величество Случай предлагает этим сотрудникам работу, которую надо выполнить за хорошие деньги, они, как правило, оказываются не готовы к такому счастью.
Я так не могу. Профессиональная деформация фрилансера мешает. Поэтому при обсуждении размера денежного вознаграждения за работу я всегда стараюсь получить для себя ответы на целый ряд следующих вопросов.
Каково соотношение отвращения и удовлетворения, получаемых от выполнения этой работы?
Зависит ли решение только от исполнителя?
За какое время я смогу решить эту задачу?
Сколько времени требуется на решение этой задачи с точки зрения заказчика?
Требуется ли присутствие моего бренного тела в офисе работодателя? Как часто и как долго?
К какому моменту времени задача должна быть гарантированно решена? (Deadline?)
Что я получу, кроме денег в случае успешного решения задачи? Профит может быть выражен в получении новых знаний, опыта, постоянного клиента, полезных связей, строчки в резюме и разных других «борзых щенков».
Одним из ключевых моментов для принятия решения является ответ на вопрос: сколько моего времени нужно потратить, чтобы «поднять» эти деньги?
По мотивам
Вообще, по моим наблюдениям, именно способность к постановке и получению ответов на такие дополнительные вопросы во многом определяет успешность человека в этой жизни. Как вы думаете, операционный директор компании «Treolan» тратит свое время на блог, посвященный секретам менеджмента, для того, чтобы подзаработать на контекстной рекламе? Или генеральный директор компании «Ланит-Терком» подрабатывает в Санкт-Петербургском государственном университете, потому что ему не хватает директорской зарплаты? И откуда они на это все берут время?
Антиподы
План, что и говорить, был превосходный: простой и ясный, лучше не придумать. Недостаток у него был только один: было совершенно неизвестно, как привести его в исполнение.
Льюис Кэрролл. Алиса в стране чудес.
Иногда кажется, что разработчики и менеджеры живут в двух разных мирах, в которых действуют разные законы физики.
Мир менеджеров детерминирован и понятен. В нем царят предсказуемые законы и точные расчеты макромира. Как можно за несколько тысяч лет заранее предсказать точные координаты любой планеты, так и в мире менеджеров можно точно определить размер бюджета любого проекта — от постройки сарая до создания космодрома. Так же точно можно определить этапы, трудоемкость, квалификацию привлекаемого персонала и необходимые ресурсы.
Вот, например, сколько скрытых возможностей принесла пандемия. Нет худа без удаленки. Это ж можно три часа, которые тратил раньше на дорогу на работу и обратно, потратить на себя любимого. Главное — правильный план составить. Например, такой: каждый рабочий день один час тратить на фитнес, второй — на изучение Java, а третий — на совершенствование английского… Просто представить затруднительно, каким можно стать супервостребованным и супердорогим специалистом через полгода с таким планом… Аж дыхание останавливается от восторга, и сердце замирает в сладостном предвкушении…
По мотивам
Правда, спустя полгода выясняется, что вместо ожидаемого похудения набрал еще плюс пять кило, программа на Java гордо выводит два слова на экран терминала, а чтение книжки на английском застопорилось на четырнадцатой странице… По-моему, про это кто-то уже писал… Конечно, если план был составлен для себя, то все объяснимо. На то есть объективные причины, почему так произошло… Но если план не удался у кого-то другого (не у себя), то это тоже понятно. Это случилось не потому, что план плохой. Это потому, что этот исполнитель был бездельником, лентяем и лоботрясом. Скорее всего, типичным представителем мира разработчиков.
Ведь мир разработчиков хаотичен и непредсказуем. Здесь царит принцип неопределенности. Нарушения пространственно-временного континуума в порядке вещей. Наблюдаются прямые ассоциации с квантовой механикой. Например, замечено, что даже пассивное наблюдение за происходящими процессами мира разработки может существенно повлиять на результат измерения.
Представители обоих миров, как правило, слабо понимают мотивацию и логику друг друга, справедливо подозревая, что их антиподы немного «не от мира сего».
Источник
Теория относительности
Подержите руку минуту на горячей плите, и эта минута покажется вам часом. А час, проведенный с милой девушкой, покажется минутой.
Альберт Эйнштейн
Любой знает по собственному опыту, что время бывает очень разным, в зависимости от времени. Времени суток и возраста.
Одну и ту же работу, над которой можно тупить три часа в конце рабочего дня в пятницу, зачастую можно сделать за 20 минут утром в понедельник. Несмотря на то, что я по природе «жаворонок», почему-то мое животное наиболее эффективно занимается кодотерапией не в рабочее время, а в темное время суток, когда все нормальные люди уже спят.
У меня сложилась теория разного осознания времени в зависимости от возраста. Согласно этой теории, каждый человек ощущает продолжительность своего времени обратно пропорционально прожитой жизни. Например, для сорокалетнего человека 15 минут воспринимаются так же, как один час для десятилетнего или полчаса для двадцатилетнего.
Однако более старший сотрудник выигрывает у более молодого за счет применения готовых решений, накопленных за трудовую жизнь. В стандартной ситуации, как правило, молодой сотрудник проигрывает ветерану, поскольку ему нужно время на поиск и апробацию подходящего решения.
С возрастом начинаешь обращать внимание, что вещи, казавшиеся раньше незыблемыми, тоже подвержены изменениям. Например, замечаешь, как растут деревья. Или то, как незаметно, но неотвратимо меняется обстановка на проекте после принятия управленческих решений…
С другой стороны, в случае существенного изменения условий, когда требуется нестандартное решение, шансы на достижение успеха у молодых гораздо выше…
По мотивам
Некоторые эксперты вообще говорят о том, чтобы успешно выполнять все свои обязанности, необходимо не больше четырех часов в неделю!
В общем, из этого всего можно сделать два важных «вывода».
Первый — ощущать себя молодым выгодно и с экономической точки зрения.
Второй — чтобы составить адекватный план по разработке программного обеспечения, надо, чтобы сотрудники были одного возраста, одинаковой квалификации и все работали за полярным кругом, где день или ночь длятся по полгода.
Не партийная номенклатура
Если Вы уверены, что ваш проектный план в точности исполнится, то Вы — идиот. Если Вы не планируете работы на проекте, то Вы — самоубийца.
Кто-то из классиков
Если хочется добиться ожидаемых результатов на проекте, рано или поздно приходишь к мысли, что эти результаты надо научиться предсказывать. До начала работ. Заранее. Вопреки всем турбулентностям быстротекущей жизни.
Предсказание начинается с того, что появляется потребность оценить трудоемкость задач, которые предполагается решить в рамках проекта.
Поначалу я обычно использовал оценку, основанную на личном опыте. На небольших проектах это работало вполне сносно. Но со временем, погрузившись в трясину менеджмента, я заметил, что мои оценки носят слишком оптимистичный характер… И чем дальше я отходил от кода, тем больше оптимизма было в моих оценках… При этом калейдоскоп из использующихся в разных проектах языков программирования, паттернов и фреймворков не добавлял точности в мои оценки. Я пытался не отставать от программистов. Но чем крупнее проект, тем труднее было совмещать на нем две роли. Оказалось, приравнивать производительность сотрудников к своей — плохая идея.
Источник
На мой взгляд, если, будучи руководителем проекта, вы участвуете в собственном проекте как разработчик, независимо от вашей реальной квалификации, сотрудники проекта будут смотреть на вас как на самого сильного игрока в команде. И рано или поздно вы рискуете незаметно превратиться в главное ограничение этого проекта.
Я начал искать способы сделать планирование на проекте более объективным.
Первым шагом к формализации планирования стало осознание небольшой разницы между задачей и подзадачей в JIRA. Многие не видят этой разницы. На их взгляд, подзадача — это типа такая же задача, только маленькая. Почти то же самое. Я сам так думал. Раньше.
Сегодня я рассматриваю подзадачу как работу определенного типа, которая может быть выполнена одним сотрудником от начала до завершения. При этом подзадача не имеет смысла без реализации всей задачи целиком. Например, проверка качества кода (code review) не имеет смысла, если, в конце концов автоматизированная функция не будет использована в программе. С другой стороны, при планировании под задачей я понимаю комлекс работ, в результате выполнения которых для проекта будет нанесена непоправимая ощутимая польза, достижение которой можно проверить и получить однозначный ответ, выполнена эта задача или нет. Например, закрыть без замечаний прохождение тестового задания по ПМИ. В идеале — получить деньги за успешную реализацию этой функциональности.
Кроме того, при планировании работ я попытался применить лайфхак, оторый неприлично назойливо повторяют в своих книжках Генри Форд и Коносуке Мацусита. А именно — попытаться унифицировать задачи творческих сотрудников в магическом деле реализации программных проектов.
Поэтому я начал с того, что сформировал номенклатуры задач, выполнение которых, с моей точки зрения, раз за разом повторяется на моих программных проектах. Ключевой особенностью этих номенклатур являлось то, что для каждой такой нормативной задачи был определен ожидаемый результат. Номенклатуру аналитических задач на своих проектах я подробно препарировал в одной из своих статей. Кроме того, была создана номенклатура задач и для сотрудников, которые создают код своими руками. Номенклатура задач для программистов, рожденная воспаленным сознанием, травмированным менеджментом, у меня самого вызывает серьезные сомнения. Поэтому буду признателен, если вы конструктивно поглумитесь над ней в комментариях.
Дополнительным шагом стал учет ранга сложности задачи при ее планировании. Методика Story Points, призванная убирать противоречия в восприятии оценки разработчиком и менеджером, в моей голове породила больше вопросов, чем ответов. Прежде всего тем, что нивелировала разницу между разным уровнем квалификации, требуемой для решения разных задач. Поэтому при регистрации задач я ввел дополнительный параметр, который характеризовал уровень квалификации, требуемый для решения задачи.
Можно по-разному оценивать этот параметр. Как вариант, например, использовать стандартные уровни, как в зарплатном калькуляторе Habr: стажер (intern), младший (junior), средний (midle), старший (senior), ведущий (lead). Но на своих проектах я стал действовать иначе. В качестве этого параметра в JIRA регистрируется должность сотрудника, которой соответствует решаемая задача. При этом я использую не только должности сотрудников на проекте, но и должности, которые на моем проекте не предусмотрены, в том числе и должности, которые не предусмотрены штатным расписанием компании.
Перечень должностей и присущих этим должностям обязанностей можно подсмотреть в профессиональных стандартах. На программных проектах, на мой взгляд, наибольший интерес представляют следующие стандарты:
программист (разработка, отладка, проверка работоспособности, модификация компьютерного программного обеспечения);
архитектор программного обеспечения (проектирование, мониторинг и контроль архитектуры программного обеспечения);
аналитик (разработка, восстановление и сопровождение требований к программному обеспечению, продукту, средству, программно-аппаратному комплексу, автоматизированной информационной системе или автоматизированной системе управления на протяжении их жизненного цикла);
cпециалист по тестированию (оценка качества разрабатываемого программного обеспечения путем проверки соответствия программного продукта заявленным требованиям);
системный администратор (обеспечение требуемого качественного бесперебойного режима работы инфокоммуникационной системы);
cпециалист по защите информации (обеспечение безопасности информации в автоматизированных системах);
руководитель разработки программного обеспечения (управление процессами разработки, отладки, проверки работоспособности и модификации компьютерного программного обеспечения, и управлению ресурсами).
Со временем оценка занятости конкретных сотрудников, построенная на основании данного параметра, может принести вам немало удивительных открытий.
Вдруг, например, может выясниться, что старший программист большую часть своего времени тратит на элементарные задачи, связанные с настройкой стендов, больше подходящие для начинающего сисадмина. Ведущий аналитик погряз в ручном регрессионном тестировании… Архитектор проекта с увлечением решает инциденты… А недавно нанятый студент самостоятельно реализует сложные интеграционные решения или согласовывает технические задания с заказчиком. Всё это может быть не так и плохо… В небольших количествах это может быть хорошим лекарством от карьерного головокружения и должностного склероза… Все зависит от той доли рабочего времени, которое тратит сотрудник на выполнение задач, которые не соответствуют его должностному положению…
По мотивам
С другой стороны, накопленная статистика открывает потенциальную возможность по оценке качества управления проектом. Насколько реальное назначение задач сотрудникам соответствует их текущей квалификации? Какую долю своего рабочего времени работник тратит на выполнение задач, не соответствующих его рангу или квалификации? Есть ли динамика изменения этих показателей во времени? Какие мероприятия были спланированы для улучшения этих показателей?
На основании этой статистики можно обосновать предложения для топ-менеджмента по изменению штатного состава проектной группы. Можно подготовить объективные данные для проведения аттестации с целью пересмотра должностей и уровня зарплаты отдельных сотрудников. Можно выстроить прозрачную карьерную лестницу для мотивации персонала. Можно принять обоснованное решение о привлечении специалистов на аутсорсинг. Много чего интересного можно замутить. Если, конечно, спонсоров проекта действительно интересует эффективность проектной группы…
Но не буду забегать вперед. MoneyDev заслуживает отдельной статьи.
Анти-героин
Часто неспособность выполнить задачу за небольшой обозримый кусок времени свидетельствует не столько о трудоемкости задачи, сколько о слабом понимании того, что конкретно надо сделать.
Максим Дорофеев
Когда я только начинал руководить проектными командами, я внутренне в тайне гордился своей способностью поднимать людей «в атаку», чтобы «допилить» горящий проект после окончания рабочего дня, в выходные и по ночам. Но со временем здравый смысл стал постепенно побеждать безудержный энтузиазм. Я узнал о существовании уровней зрелости управления, а также то, что начальный уровень зачастую называют уровнем героев, поскольку проект выживает только за счет постоянного совершения трудовых подвигов. Сегодня для меня уровень зрелости руководителя гораздо лучше характеризует его способность достигать целей проекта без организации авралов.
