Однажды, давным-давно, на Хабре была опубликована статья, в которой было высказано предположение, что главной причиной беспокойства, бессонницы, нервных срывов и головной боли на программных проектах являются страхи, которые преследуют сотрудников этих проектов даже, казалось бы, при внешне успешной обстановке. Для того, чтобы проверить эту гипотезу, и в поисках причин, по которым любимая работа на IT-проектах начинает вызывать отвращение, в этой же публикации был запущен открытый опрос. Предвзятый и субъективный анализ результатов этого опроса вы найдете в статье ниже. Любая конструктивная и оптимистичная критика приветствуется.
Боитесь ли Вы молнии?
Когда речь заходит об опросах или профессиональном психологическом тестировании, я почему-то всегда вспоминаю одну сказочную историю, которую услышал однажды несколько лет назад. Тем более, если речь идет об исследовании анатомии страха и эффективном менеджменте.
Эту историю мне рассказал случайный знакомый, пенсионер, с которым я однажды разговорился на лавочке в парке. По его словам, когда-то он был директором предприятия, ведущего в одной из отраслей нашего когда-то всенародного хозяйства.
Несмотря на то, что эта отрасль когда-то была одной из важнейших для нашей страны, с началом прогрессивных реформ, которые потрясли всю нашу экономику в конце прошлого века, эта отрасль постепенно, но неотвратимо все больше и больше атрофировалась, несмотря на все благие намерения. Очевидно, что складывающаяся ситуация была вызвана неэффективным менеджментом, излишней бюрократией и нецелевым расходованием финансовых средств. Для того, чтобы спасти ситуацию, были приняты нетрадиционные инновационные меры. На руководство отраслью был назначен человек абсолютно независимый, заведомо некоррумпированный, поскольку ранее вообще в этой отрасли никак не отметился, но прекрасно разбиравшийся в оптимизации налогообложения, корпоративных финансах и эффективном менеджменте.
Уже скоро после его назначения стало совершенно очевидно, что одним из главных препятствий для инноваций было засилье ретроградов, которое царило в главке. Заскорузлые узколобые ортодоксы, за всю свою жизнь ничего не видевшие кроме своих закопченных заводов, просто не хотели понимать, какие перспективы открываются в новых условиях. Наоборот, они всячески выискивали новые причины, чтобы доказать, что в этих условиях развитие отрасли просто невозможно. Поэтому одним из первых нововведений, которые новый начальник произвел в главке, стала отправка всех устаревших экспертов на давно заслуженную пенсию. На их место были взяты новые сотрудники. Точнее, по большей части сотрудницы. Молодые, светловолосые, длинноногие, со всем согласные, не видавшие в своей работе никаких проблем, а только открывающиеся перспективы. Настоящие профессионалы современного менеджмента с дипломами российских бизнес-школ, благословленных крупнейшими учебными заведениями Европы и США.
Обстановка в главке значительно изменилась. После проведенного евроремонта, потемневшие от времени картины давно забытых классиков соцреализма в запыленных позолоченных рамах, ежедневно напоминавшие о тяжелых трудовых буднях заводского люда, сменили необременительные успокоительно-толерантные пейзажи современных художников. Старые полотна, по случаю, удалось втюхать какой-то коммерческой фирме по цене мусора. По слухам, они нашли свое место в каком-то забытом Богом аукционе доме престарелых.
В коридорах главка все чаще стали слышны фразы, как будто процитированные из современных учебников по менеджменту и маркетингу. Казалось, еще немного и сотрудники окончательно перейдут на общение на одном из распространенных западноевропейских языков. Тяжелый дух застоя и мрачного неприятия перемен стремительным вихрем вытеснили запах французских духов и страстное желание выполнить любую задачу ради достижения великой цели. Как у героя Сергея Маковецкого: «Я из всего умею стрелять. Только покажите как».
Однако на предприятиях отрасли по непонятным причинам революционные изменения почему-то не произвели должного эффекта. Очень скоро стала понятна недостаточность принятых мер. Большинство директоров предприятий с маниакальным упорством не желало осознавать прогрессивные устремления нового руководства, а зачастую просто саботировало внедрение в свою деятельность инновационных методов управления, эффективность которых была уже многократно проверена во всем мире. По крайней мере, именно это утверждали многочисленные рекламные буклеты всех бизнес-школ. Поэтому новый начальник предпринял следующий решительный шаг по кардинальному исправлению ситуации к лучшему – было принято решение провести поголовную аттестацию профпригодности всех ключевых руководителей.
Понятное дело, раньше о стандартизированном многофакторном методе исследования личности (MMPI) слыхом не слыхивали. А судя по вялым результатам проводимых реформ, руководство предприятий было просто пропитано какими-то неадекватами, которые просочились во времена застоя.
Всем известно, что рыба гниет с головы. Поэтому для проведения аттестации в Москву пригласили директоров ведущих предприятий отрасли. Чтобы обеспечить полную объективность и непредвзятость этой проверки, на первом этапе аттестация предполагала проведение стресс тест-опросов на проверку когнитивных способностей и психологической устойчивости.
Для этого всех участников опроса собрали в одном большем конференц-зале. Новые сотрудники главка в одинаково белых блузках и коротких черных юбках, больше похожие на стюардесс большого офисного пепелаца, чем на государственных чиновников, цокая высоченными каблуками, раздали каждому из участников анкету больше чем на полтысячи самых разных вопросов. И аттестация началась.
Моему знакомому досталось место в центре зала. За столом впереди него сидел руководитель одного из смежных крупных предприятий. По всему было видно, что с самого начала этот человек находился не в своей тарелке. Суровый директор, прошедший за три десятка лет все ступени карьерной лестницы от простого инженера горячего цеха до руководителя одного из крупнейших предприятий индустрии, он явно не понимал целей этого судьбоносного для отрасли мероприятия. Заполняя анкету, он постоянно ерзал на своем стуле и затравленно озирался по сторонам со взглядом матерого волка, загнанного за флажки. Через некоторое время флажки-вопросы, видимо, совершенно загнали его в тупик. Складки на его бритом затылке стали постепенно багроветь. Не найдя ничего лучше, он обернулся к моему знакомому и негромко прошипел:
— Ты не знаешь, как отвечать, если вопросы какие-то дурацкие?
— А что за вопрос?
— «Боитесь ли Вы молнии?»
— Да отвечай как-нибудь. Какая разница? На производство это не влияет.
— Да мне непонятно, так это в детстве или сейчас.
— Да сейчас, конечно, сейчас.
Видимо, не удовлетворившись таким ответом, через некоторое время суровый директор с видом утопающего поднял руку. Через весь зал, звонко отбивая дробь по сверкающему паркету и собирая оценивающие взгляды мужской части собравшихся, к нему подошла одна из присутствующих «спасателей» и, всем своим видом демонстрируя готовность оказать искусственное дыхание помощь, склонилась над багровым телом сурового директора. Внимание сотрудника главка еще больше смутило не привыкшего к ласке производственника.
— Сan I help you? Чем я могу Вам помочь?
— Да вот тут вопрос... Непонятный... — выдавил из себя директор.
— А что за вопрос?
— «Боитесь ли Вы молнии?»
— А что именно непонятно?
— Да мне непонятно, это в детстве или сейчас? — прохрипел суровый директор.
— Да не волнуйтесь Вы так. Сейчас. Конечно, сейчас.
Видимо, получив второе дыхание после разъяснения консультанта в отношении непонятного вопроса, директор на какое-то время успокоился и принялся усердно проставлять галочки в своей анкете. Однако через несколько минут он стал снова беспокойно ерзать на своем стуле. Складки на затылке побагровели еще сильнее. Безнадежно бросив взгляд на окружавших его коллег, которые беззаботно заканчивали заполнять анкету, суровый директор вновь поднял руку. И опять как в первый раз, гулко стуча каблучками-шпильками к нему подошла ослепительно уткогубая сотрудница главка.
— Что у Вас снова случилось?
— Да вот опять! Вопрос непонятный! – почти выкрикнул суровый директор.
— А что за вопрос?
— «Вы когда-нибудь хотели убежать из дома?»
— И что непонятно?
— Мне непонятно, это в детстве или сейчас?!
— Да сейчас. Конечно, сейчас.
То что произошло потом, по всей видимости не планировали ни организаторы этого мероприятия, ни сам виновник произошедшего, ни тем более стоявшая рядом обладательница накладных двухсантиметровых ресниц, густо обрамлявших глаза, неожиданно ставших круглыми как два светлоголубых блюдца. Услышав ответ консультанта, суровый директор, вдруг внезапно швырнув ручку на пол, вскочил со своего места красный и мокрый, как будто в лицо ему плеснули крутым кипятком. «Я оказываюсь отвечать на все эти ваши провокационные вопросы!! – закричал он, вцепившись в край стола побелевшими пальцами с видом приговоренного, которого затаскивают на эшафот. - Я вообще оказываюсь принимать участие в этом мероприятии!!!»
Потом в курилке, обсуждая произошедшее, один из участников опроса, который был в числе первых «отличников», сдавших свою анкету, устало высказал свое мнение: «И что это Иваныч так близко к сердцу эту интермедию принял? Первый раз, что ли, ритуальные танцы танцевать? Я неделю назад, сразу после того как пришла телеграмма о этом мероприятии, направил сюда своего зама по компьютерным делам. Для обмена, так сказать, бесценным опытом. Он с местными эникейщиками быстро договорился. Два ящика коньяка – и сегодня все эти бумажки вообще без моего участия правильно заполнили. Делов-то...»
Правила фальсификации результатов
Я считаю, что совершенно неважно, кто и как будет голосовать; но вот что чрезвычайно важно, это кто и как будет считать голоса
И.В. Сталин
Первым результатом проведенного опроса стало для меня то, что я совершенно не умею проводить подобные опросы. Прежде всего я ошибся в предполагаемом количестве участников. Мне казалось, что это количество будет соизмеримо как минимум с 10% от количества просмотров первой статьи. Оказалось, что я ошибся в несколько раз.
Возможно, это случилось потому, что участие в опросе было предложено честным сотрудникам проектных команд, в которых казалось бы некого и нечего бояться. Вероятно, это слегка абсурдное исходное предложение повлияло на количество участников.
Отдельные вопросы, на которые я хотел бы получить ответы, пришли на ум и были добавлены уже гораздо позже публикации опроса. Чем, например, объясняется гораздо меньшее количество ответов на вопросы об индивидуальных планах работ и об обучении.
Чтобы излишне не пугать респондентов, вопрос, который требовал обязательного ответа, был только один: «Какая ваша роль на проекте?». Поэтому проанализировать результаты в разрезе отдельных групп ответов в полном объеме не представляется возможным ввиду отсутствия этих ответов Например, 7 участников опроса не смогли выбрать тип IT-проекта, в котором они принимают участие. Поэтому не всегда сумма участников по всем группам равна общему числу респондентов.
Кроме того, многие респонденты проявили творческий подход и отразили в ответах свое развернутое мнение. Для включения таких ответов в мой анализ я их волюнтаристски переклассифицировал, опираясь на собственный опыт и свое субъективное мнение. Например, ответ «и швец, и жнец, и на балалайке игрец» на вопрос о занимаемой должности на программном проекте я переделывал просто в «программист». Или если на вопрос о главной причине проблем на проекте респондент отмечал несколько вариантов, то я за него выбирал только первый фактор из указанных. Или авторский ответ «Отсутствие заинтересованности в успешности проекта у каких-либо его участников» перебивал в предопределенный вариант «низкое качество менеджмента проекта».
Умные люди рекомендуют перед тем, как показывать какие-то графики и гистограммы, оценить степень доверия к этим картинкам с помощью какого-то объективного инструмента. Учитывая вышеуказанный волюнтаризм и субъективизм в отношении фальсификации ответов, методы статистической проверки к получившимся результатам не применялись. Но желающие могут попробовать научно-обоснованно дискредитировать подтасованные выводы этого опуса на основании исходных материалов.
Однако несмотря на все мои попытки исказить материалы этого независимого опроса, было получено несколько любопытных результатов.
Проклятие IT-проектов
IT-проекты похожи на черные дыры: они поглощают бесконечное количество времени, денег и ресурсов, и редко дают ожидаемые результаты.
Томас Хоффман
Когда-то давным-давно я случайно познакомился с результатами анализа эффективности индустрии программных продуктов, которые проводит компания Standish Group. С тех пор я наблюдаю за результатами ежегодного отчета этой компании, который весьма показательно называется CHAOS Report. Я руководствуюсь материалами которые иногда просачиваются в общественный доступ. Однако я решил с помощью своего опроса оценить степень влияния основных негативных факторов на IT-проектах. В ответах на вопрос «С Вашей точки зрения какая ГЛАВНАЯ причина проблем на проекте?» первое место безоговорочно занял ответ «Низкое качество менеджмента на проекте». Руководители («белые воротнички») в этом уверены даже больше чем исполнители. Это, конечно, немного странно, ведь эти проблемы они сами и создают.
Что любопытно, в отчете Standish Group за 2020 год утверждается, что весьма распространенный миф, в который пора перестать верить – это то, что причиной проблемных и неудачных проектов являются неполные и противоречивые требования. И на мой взгляд, это соответствует действительности, поскольку неполные и противоречивые требования – это скорее следствие низкого качества организации управления этими самыми требованиями.
Попробуем выявить основные причины такого состояния дел.
Страшно жить
Люди, застигнутые катастрофой уже не боятся. Пугает только неизвестность.
Антуан де Сент Экзюпери
Изучив результаты опроса, нельзя было не почувствовать гордость за высокие моральные принципы сотрудников IT-отрасли. Оказалось, что независимо от должностного положения, второе место среди страхов всех сотрудников IT-проектов устойчиво занимает страх выполнить свою работу с недостаточным качеством. Также значительное место в сознании сотрудников занимают опасение подвести коллег и тревога показать свою некомпетентность.
Возможно, из-за предвзятого отношения к построению опроса основная гипотеза полностью подтвердилась: более двух третей фобий у сотрудников программного проекта прямо или косвенно связаны с их недоверием к своему руководству. И что примечательно, постоянный страх плохого руководства портит жизнь менеджерам ничуть не меньше, чем исполнителям.
Получается, по большому счету, чтобы сотрудники жили счастливо на IT-проекте, ими надо просто нормально управлять? Что значит нормально? Попробую предположить. Ну, например, заблаговременно планировать работы. Или обеспечивать подготовку сотрудников к решению предстоящих задач. Или, может, просто конкретизировать границы должностных полномочий и обязанностей? Как бы не так. Менеджеры IT-проектов не ищут легких путей.
Обычные дела
Жаль подмога не пришла,
Подкрепленье не прислали...
Что ж, обычные дела....
Андрей Барышев. Подмога
Однажды при обсуждении распределения обязанностей на моем проекте, один из опытных руководителей, имеющий стаж более 25 лет в IT-отрасли, спросил меня: «А разве старшие специалисты обязаны тратить свое рабочее время на обучение младших? И почему Вы делегируете планирование работ аналитикам?» И был прямо-таки поражен «открытием», что в своих «завышенных» требованиях я опираюсь на типовые должностные обязанности.
Этот случай хорошо иллюстрирует результат, полученный при ответе на вопрос «Вы видели свои должностные обязанности?»
По результатам опроса, в среднем менее 7% сотрудников ежедневно руководствуются в своей работе перечнем своих служебных обязанностей. На мой взгляд, положение, когда сотрудник последний раз видел свои обязанности только при подписании договора, косвенно намекает не только на отсутствие механизмов аттестации, но и на ряд других скрытых проблем. Причем такая ситуация фактически не зависит от типа программного проекта.
Казалось бы, если посмотреть на распределение относительно руководства и исполнителей, руководители должны показать образец уважения к основному инструменту, на котором зиждется их власть. Однако процент руководителей, не видевших свои должностные обязанности, даже больше чем у исполнителей.
Как говорили мне многие руководители: «Какая разница что там написано? Главное, чтобы там была фраза «обязан исполнять все указания руководства». Честно говоря, эта фраза мне сильно напоминает один распространенный лозунг из моего пионерского детства... При этом бывает, что те же самые руководители из кожи вон лезут, чтобы соответствовать современным тенденциям кадрового менеджмента и искренне не понимают источники «внезапно» возникающих кадровых проблем.
Зачастую, главным источником фобий на проектах является отсутствие должностных инструкций с четким распределением зон ответственности. Которые согласованы и одобрены руководством. Чтобы фраза сотрудника «Эта задача не в моей компетенции» не не приравнивалась к предательству Родины... А при отсутствии согласованных должностных обязанностей все сотрудники занимаются всем и ничем. И ресурсов на таких проектах всегда мало. И рабочего времени всегда не хватает... И по любому поводу всех сотрудников такого проекта начинает колбасить, плющить и трясти... Потому, что никто не знает точно, для кого это повод начинать волноваться... Поэтому волнуются все сразу... Только вида не показывают... Чтобы не назначили виноватым...
В выигрыше в таких условиях всегда остаются те, кто лучше всего приспосабливается под изменчивое настроение руководства. Со всеми вытекающими последствиями... Шумихой, неразберихой, безуспешным поиском ответственных, наказанием невиновных и награждением непричастных... Не за заслуги, а за услуги...
Не знаю как вам, мне вполне хватает требований зафиксированных в следующих профессиональных стандартах:
Если Вы, ну совершенно случайно, узнаете, что у вас на проекте нет должностных инструкций, или они не совсем актуальные, то в качестве таких инструкций можно использовать ссылки на соответствующие разделы этих профстандартов. Причем, для этого не стоит переписывать текущие трудовые договора. Просто при найме новых сотрудников и при назначении ветеранов на новые должности , укажите в новом трудовом договоре на основании какого раздела трудового стандарта предъявляются требования к служебным обязанностям.
Если Вы сумеете согласовать с начальством и получить одобрение на применение профессиональных стандартов в качестве должностных инструкций, то это позволит убить сразу несколько «зайцев».
Во-первых, сразу снимаются все вопросы сотрудников связанные с легитимностью требований в отношении должностных обязанностей. Здесь может быть сделано множество удивительных «открытий». Например то, что сотрудник имеющий в названии своей должности прилагательное «старший» или «ведущий» должен решать ряд менеджерских задач и заниматься обучением коллег. А руководители вдруг могут узнать о том, что для успешного управления, быть примером для своих подчиненных недостаточно.
Во-вторых, у вас появляются фундамент для того чтобы объективно объяснить сотруднику его недочеты в работе. И наоборот – обосновать перед руководством необходимость повышения зарплаты сотрудника.
В-третьих, эти документы позволяют отстоять перед заказчиком необходимость привлечения к проекту необходимых специалистов. И перед своим топ-менеджерами тоже.
В-четвертых, на основании компетенций, описанных в этих стандартах, можно строить предсказуемые карьерные лестницы и планировать обучение сотрудников.
В-пятых, эти стандарты помогают адекватно составлять индивидуальные планы сотрудников.
Вы можете спросить меня: «А что такое индивидуальные планы?»
Карты будущего
Мы можем вернуться, когда захотим.
Но не способны увидеть новое.
Мы не можем идти дальше.
Пока нет навигатора, мы обречены бродить только по знакомым мирам.
Вадим Панов. Кафедра Странников
Однажды, обсуждая причины неурядиц на проекте, мой коллега стал возмущаться, что вышестоящее руководство не предоставило ему план его работ. Однако мой встречный вопрос о том, почему он не рассматривает перечень назначенных на него задач в JIRA как план работ, вызвал у этого сотрудника когнитивный диссонанс (далее под JIRA будут пониматься любые автоматизированные системы управления программными проектами, а под Jira – продукт компании Atlasian). Еще большее смятение вызвало у него мое замечание о том, что, с моей точки зрения, его работы лучше всего спланировал бы он сам на основании тех целей, которые должно поставить перед ним его начальство.
К сожалению, по моему опыту, зачастую многие руководители тоже НЕ воспринимают JIRA как основное средство для планирования работ сотрудников. Не так давно убил уйму времени на попытки доказать руководству тезис о том, что план развития сотрудника в полном объеме должен быть отражен в JIRA наряду с проектными задачами. Руководство почему-то считало, что такой план будет гораздо эффективнее, если его составить в Word или Excel. Что касается создания предварительных набросков плана, не спорю, возможно выбор этих инструментов будет лучшим решением. Однако, с опытом я приобрел твердую уверенность, что ВСЕ утвержденные планы должны обретать форму задач в JIRA/Redmine (или подобной системе). Нет задачи в JIRA – нет плана.
Вместе с тем, судя по результатам опроса, более половины сотрудников не знают о том, что трудовую деятельность можно и нужно как-то прогнозировать.
При этом многие руководители, принявшие участие в опросе, с потрясающей легкостью признались в отсутствии необходимости прогнозирования своей деятельности.
Разбирая нетиповые ответы на этот вопрос, я выявил для себя одну особенность. Некоторые респонденты даже не поняли, что вопрос был задан именно в отношении индивидуальных планов, а не утвержденных календарных планов проекта.
Регулярная сверка планов с реальным состоянием дел на проекте, на мой взгляд, является одной из ключевых задач управления. Если вы ухитряетесь формировать задачи небольшой трудоемкости, такой контроль можно достаточно точно вести по количеству решенных задач. У меня так не получается. Поэтому один из вопросов, на который я хотел получить ответ, был вопрос о применимости таймтрекинга на IT-проектах.
Результаты по таймтрекингу я оставлю без комментариев. Но хотелось бы узнать у читателей Хабра, что они думают о таймтрекинге и оптимальном горизонте планирования для персональных планов.
Непроизводственные потери
Прежде чем создавать машины, мы создаем людей.
Дао Тойота
Сегодня, если открыть любую книжку, посвященную способам построения успешной компании, то наверняка вы найдете в ней тезис о том, что основа основ достижения успеха кроется в организации обучения сотрудников и построении прозрачной карьерной лестницы.
Однако мой опыт работы в разных компаниях говорит скорее о том, что расходы на обучение сотрудников воспринимаются руководством скорее как непроизводственные потери времени. И если случается отправка сотрудника на обучение, то это преподносится не как часть трудовой деятельности, а как награда и акт филантропии в отношении сотрудника.
Увы, результат ответов об организации обучения на IT-проектах это подтверждает.
Судя по этим ответам, обучение вообще не является составной частью деятельности в одной из самых быстроменяющихся отраслей производства. По крайней мере так это видят участники опроса.
Меня особенно умиляет компании, в которых обучение проводится по мере необходимости. Будем учиться плавать, после того как встретим речку. На мой взгляд, это явный сигнал о запоздалом осознании необходимости заблаговременного планирования этого вида деятельности.
На своих проектах на вопросы обучения я смотрю с точки зрения не сильно распространенной. Для начала, я стараюсь создать условия, чтобы личные цели сотрудников были максимально близки целям, стоящими перед командой. Поэтому, как только я знакомлюсь с новым сотрудником, я говорю ему: "Давай поработаем над улучшением твоего резюме. Чтобы ты смог себя продать подороже на рынке труда. Давай обсудим какие разделы твоего резюме будем улучшать?". А как улучшить резюме, если на новом месте работы не научиться ничему новому?
К слову, я сам не являюсь сторонником обучения сотрудников на всяческих курсах, реклама которых обещает за полгода поднять ваши знания и умения в IT с нуля до уровня уверенного "мидла". Чем дипломы подобных курсов, меня гораздо больше привлекает, если сотрудник может похвастаться своими достижениями, дав ссылку на GitHub или на сайт реального пет-проекта.
Поэтому для развития сотрудников я считаю лучшим способом заведение внутреннего открытого проекта, участие в котором сотрудники могут продемонстрировать даже если покинули компанию. Не нарушая NDA. Проекта, на котором проектная команда, в рамках рабочего времени, не боясь сорвать сроки, может решать важные, но несрочные задачи. Например апробировать применение новых технологий. Или посмотреть на что способен стажер. Или на что способен ветеран, претендующий на более высокую должность. Со временем, такой проект может стать платформой для создания нового продукта.
Не так давно, мы дискутировали с одним топ-менеджером о таких необходимости таких проектов. Он бездоказательно безапелляционно утверждал, что коммерческая организация не может позволить себе такой роскоши. Ведь вероятность, того что такой проект станет продуктом ничтожно мала! В идеале, руководителю проектов нужно следить, чтобы все рабочее время сотрудников расходовалось на 100% только на проекты приносящие прибыль! По моему мнению, именно такой подход менеджмента является одним из гарантированных способов отравить жизнь сотрудников проектной группы, источником многих скрытых проблем и страхов на проектах всех типов. Спросите у Елены Федурко. Она не даст соврать... Да и Макс Дорофеев подтвердит... Правда некогда читать их опусы... Проекты горят...
Утилизация рабочего времени сотрудников это показатель эффективности труда, который показывает, насколько хорошо используется рабочее время сотрудников. Он рассчитывается как отношение полезного времени (времени, затраченного на выполнение работы) к доступному времени (общему количеству часов, которое сотрудник может работать в течение определённого периода).
Утилизация... Я конечно понимаю, что речь идет об употреблении с пользой... Но в моем русскоязычном сознании почему-то это слово создает совсем другие ассоциации... Пугающие... Кстати, вы никогда не задумывались, что время доступное для работы сотрудника, может быть сильно меньше, чем период рабочего времени, который зафиксирован в трудовом договоре? Просто потому, что у этого сотрудника нет задач, которые необходимо решить. Если вы начнете считать утилизацию рабочего времени с учетом этой "мелочи", вас может ждать множество удивительных открытий... Нет, конечно, если начальство скажет мы всех быстро утилизируем... Мы что, не понимаем? Если надо - значит надо. Мы можем. Даже на 120%... Бери лом, иди плац подметать... Чего только не сделаешь ради красивых отчетов...
Что касается меня, то рамках бюджета времени своей проектной команды я нахожу время на занятие всякими некоммерческими "глупостями". О своем R&D-проекте и о некоторых достигнутых результатах, я уже как то рассказывал на Хабре. Я привлекаю к этому проекту только тех сотрудников, которые добровольно желают участвовать в этом "безобразии". Без насилия. И странная вещь. Эти сотрудники, как правило, успевают справляться со своими основными служебными обязанностями гораздо быстрее тех, которые такими проектами не интересуются. И я почему то уверен, что если вы сделаете инструмент с помощью которого успешно решаете задачи в которых вы кровно заинтересованы, успех на рынке такому инструменту гарантирован. Вы, к слову, ничего не слышали о таких проектах как Bootstrap или SQLite? Если если мне не изменяет память, эти неприбыльные open-source проекты были сделаны внутри каких то коммерческих организаций... Кстати, одной из разновидностей таких внутренних проектов, могут быть проекты по созданию интерактивного обучающего курса который посвящен обучению потенциальных пользователей вашего продукта. Или обучению стажеров для вашей команды... Лучший способ чему то научиться - это обучить кого-нибудь.
Кроме этого, для обучения сотрудника, я поручаю этому сотруднику задачи, квалификация для решения которых превышает текущий уровень его компетенций. И позволяю ошибаться при решении таких задач. И самостоятельно решать эти ошибки. Например, чтобы аналитик подготовил отчет по этапу договора за руководителя проекта и отчитался перед Заказчиком. Или начинающий программист обеспечил сборку версии. Под присмотром, наставника, конечно. И потом, статистика таких решенных задач служит объективным основанием для повышения зарплаты и должности.
Наряду с назначением наставников, ответственных за обучение новых сотрудников, на нашем проекте подготовлен типовой набор учебных материалов по основным технологиям и подходам, которые мы используем. Эти материалы живут на проекте прямо в JIRA в форме задач, которые надо изучить «молодому бойцу». Например, такая типовая задача содержит в своем составе перечень основных вопросов и понятий, которые требуется усвоить, ссылки на наиболее удачные видеокурсы по данной теме на YouTube, учебники и статьи. По отдельным направлениям у нас получилось провести ряд внутренних семинаров, которые мы записали на видео и дополнили ими учебные материалы. Не могу сказать, что все подготовленные материалы по изучению технологий одинаково высокого качества, тем не менее их наличие позволяет в минимальные сроки создавать в форме задач JIRA индивидуальные программы ввода в строй новых сотрудников на проекте, с учетом их исходной квалификации и тех задач, которые они будут решать.
Кстати, выписку из Jira с перечнем вышеописанных задач, решаемых конкретным сотрудником, я называю планом индивидуального развития этого сотрудника.
Кроме вышеперечисленного, для нашей проектной команды работает правило, что каждый сотрудник успешно выполняющий свои должностные обязанности, может один раз в год получить обучение на 1-2 недельных курсах направленных на повышение его эффективности в интересах проектной команды. Однако, несмотря на мою поддержку, мои коллеги почему-то не спешат пользоваться этой преференцией. Причиной остается все тоже низкое качество подобных курсов... Превращение образования в доходную отрасль бизнеса привело к тому, что факт обучения в отдельных "учебных" учреждениях лучше не афишировать... Может негативно повлиять на оценку компетенций при приеме на работу...
А может кто нибудь подскажет что-нибудь стоящее для системных аналитиков и программистов C# ?
В вашей компании применяют более эффективные способы повышения компетенций сотрудников? Поделитесь в комментариях!
Автоматизация CHAOS
Всякая новая технология — это не просто инструмент, а целая экосистема возможностей и угроз.
Шерил Сэндберг
Иногда начальство ставит передо мной задачу присмотреть какую-нибудь систему управления проектами взамен Jira. Бывает даже контекстная реклама подбрасывает им руководители сами находят такую систему и просят меня оценить перспективы применения ее на наших проектах. Поэтому одной из задач, которые я ставил при проведении этого опроса, была потребность выяснить, какие инструменты наиболее эффективны популярны в непростом деле автоматизации IT-проектов.
Хотя контакты с представителями отделов продаж этих отечественных систем вызывают у меня смутные подозрения о том, что разработчики этих систем слабо представляют, что именно они продают. Когда я общаюсь с этими представителями, обычно я задаю им один и тот же вопрос: «Убедите меня, почему я должен приобрести именно вашу систему управления проектами». Почему-то ответы представителей от разных производителей звучат как под копирку (мысли вслух):
— «Наша система полностью отвечает всем требованиям импортозамещения» (И какой профит даст мне переход с иномарки на отечественный продукт?);
— «У нашей системы очень удобный и дружелюбный интерфейс» (Да меня и текущий интерфейс вполне устраивает...);
— «Для настройки нашей системы используются более 300 параметров, и вы можете настроить ее под любой свой проект» (Господи, я скорее умру прежде, чем ее настрою...);
— «Наша система поддерживает почти все функции Jira» (Почти? Не понял, зачем мне менять Jira на мыло, если я потеряю в функциональности);
— «Наша компания предлагает очень удобные условия лицензирования» (Не понял, я кредит беру или систему управления проектами?).
Иногда эти сотрудники пытались мне рассказать о каких-то киллер-фичах своих продуктов, однако при этом не могли ответить на встречный вопрос: «Какие именно проблемы на моем проекте поможет мне решить эта киллер-функция?»
Вы, наверное, подумали, что в отличие от нерадивых сотрудников отдела продаж руководители команд, которые эти продукты разрабатывают, конечно, отчетливо понимают конкурентные преимущества своего продукта?
Однажды на учебных курсах по менеджменту жизнь меня свела с вице-президентом одной компании, которая недавно выпустила на рынок собственную систему управления проектами. Реклама характеризовала этот продукт не больше не меньше как «киллер Jira». Когда мы обсуждали достоинства этой новой системы, я спросил у него: «А за счет каких именно преимуществ ваша система должна «убить Jira» на рынке автоматизации управления проектами?» В качестве примера я вспомнил, какое влияние оказало появление нарезного стрелкового оружия на результаты Крымской войны середины XIX века. «Какие «нарезы» вашей системы позволят мне обойти конкурентов? – спросил я. – Только не рассказывайте мне про импортозамещение и низкую стоимость эксплуатации. Это не повод менять Toyota на Ладу-Калину». Мой визави почему-то не нашел, что мне ответить. Правда, после нашей беседы рекламу этого продукта, содержащую словосочетание «киллер Jira», я больше не встречал.
Другой показательный случай произошел со мной, когда я решил пройти собеседование на вакансию руководителя внедрения в госсекторе одной отечественной автоматизированной системы управления проектами, которая позиционировалась вендором как одна из самых эффективных на рынке РФ. Судя по информации на сайте компании, на тот момент эта система была успешно внедрена в работу более чем в трех сотнях различных организаций (на начало 2025 года более чем в 500 организациях). Порывшись на сайте Госзакупок я оценил для себя финансовые возможности для развития этой системы. Только один из договоров по внедрению этой системы на одном из предприятий промышленности тянул на 150 миллионов тогдашних денег... Я прям в тот момент, помню, ошалел от открывающихся возможностей... Собеседование проводили несколько человек, среди которых был ведущий конструктор и один из замов генерального. Это мероприятие больше было похоже на небольшой экзамен по прикладным аспектам применения PMBoK. В конце собеседования я со своей стороны смог задать несколько вопросов, касающихся организации работ по созданию этой системы. Я жаждал уточнить некоторые детали. «Конечно, для управления проектными работами по внедрению и доработкам вашей системы, – спросил я, – ваша команда использует эту же систему?» «Нет, что Вы, – ответили мне, – это же другое. Наша команда разработчиков использует Jira». Детали почему-то я уже не захотел уточнять.
Опрос, которому посвящена эта статья, проводился в начале 2022 года, поэтому в настоящее время в связи со всплеском попыток перехода на отечественные системы ситуация, возможно, сильно отличается. Но мне кажется, что полученные результаты будут интересны и сегодня.
Обычно, когда проводится исследование рынка каких-либо продуктов, на результирующих гистограммах наблюдается плавное распределение полученных результатов, в которых значение метрики постепенно понижается от фаворита к аутсайдерам. В случае рассмотрения рынка автоматизации управления IT-проектами фактически наблюдается картина «Гулливер и лилипуты». Jira является непререкаемым лидером рынка. У меня довольно много знакомых работает за рубежом в сфере IT. Мои попытки выяснить у них, что они используют для автоматизации своих проектов, всегда заканчивались одним и тем же ответом – Jira.
В поисках причин такого состояния дел я пробовал изучить устройство других систем управления проектами, благо многие вендоры дают период бесплатной апробации и даже предлагают для этой апробации шаблоны предзаполненных проектов. В результате этих изысканий я пришел к выводу, что практически все отечественные производители просто копируют базовый функционал Jira, не заморачиваясь изучением реальных проблем управления программными проектами, которые в настоящее время остаются нерешенными (см. выше статистику Standish Group).
Этот фактор определяет разрыв между Jira и другими системами управления проектами. Зачем покупать новую отечественную реплику, если можно использовать ранее хакнутый приобретенный оригинал?
Jira стала инструментом, неразрывно связанным с внедрением Scrum и Kanban-методологий. В большинстве случаев компании, даже не имея глубокого понимания методологий управления проектами, выбирают Jira как готовое решение благодаря её ассоциации с этими практиками. Однако это создаёт эффект «суррогатного управления»: наличие готового инструмента подменяет понимание целей, задач и функций управления. Jira воспринимается как универсальный инструмент, который решит все проблемы управления сам по себе. Вместе с тем, копирование вендорами Jira фактически оставляет за рамками применения альтернативные подходы к управлению проектами. Например, подходы, о которых писал Элияху Голдрат. Кроме того, необдуманное применение типовых шаблонов развертывания проектов в Jira может привести к ситуации, когда стремление соответствовать формальным стандартам подменяет собой эффективность бизнес-процессов. На эти аспекты обращает внимание внимание Джон Эванс в своих статьях Смерть Jira и Jira - антипаттерн.
Что имеем в результате?
Jira остается de facto стандартом, во многом за счёт отсутствия конкурентов, которые предлагают методологически обоснованный подход, подкрепленный успешными результатами применения.
Компании, которые копируют Jira, не добавляя методологической ценности, лишь усиливают доминирование Atlasian на рынке.
Без развития управленческих практик структура рынка останется без изменений, и доля Jira будет снижаться медленно, если вообще будет.
С другой стороны, на мой взгляд, эта ситуация выявляет потенциальную нишу на рынке автоматизации управления для нового продукта, который действительно сможет уменьшить боль проектных команд и создать предпосылки для увеличения их эффективности. И решение проблем лежит не в области частных доработок автоматизированных систем управления проектами, а в области методологий управления, в рамках которых применяются эти системы.
Кстати, все тот же отчет Standish Group за 2020 год относит к числу распространенных иллюзий утверждение о том, что выбор инструмента управления определяет успешность программных проектов. На мой взгляд, вендор, который сосредоточит усилия на внедрении методологий, а не инструментов, имеет все шансы выхода на простор нового голубого океана.
Необходимо отметить, что одно из ошибочных ограничений проведенного опроса также могло оказать значительное влияние на конечный результат. А именно то ограничение, что респондент мог выбрать только одну систему управления проектами. Как показала практика, во многих командах для автоматизации управления одновременно используется несколько инструментов. Например, для оценки ресурсов используется MS Project или (и) Excel, и в то же время команда разработки применяет Jira или Redmine. Хотелось бы исправить эту ошибку. Кроме того, очень бы хотелось узнать, как повлияли три года активного импортозамещения на рынок систем управления проектами. Поэтому приглашаю всех сочувствующих пройти еще один короткий опрос, в котором возможен одновременный выбор нескольких систем управления проектами.
Рецепты управления
Любой командир корабля только тогда заслуживает уважения, когда сумеет сделать жизнь своих подчиненных невыносимой.
Геннадий Антонович Радзевский
Одним из вопросов, который меня интересовал, был вопрос о том, какие методологии управления применяют руководители на программных проектах.
Вероятно, вы спросите меня что такое ХиС? С легкой руки одного из респондентов я объединил методологии «Барин и холопы», «Один за всех и все не за кого», «Чайка-менеджмент», ScrumBut в один класс «Хаос и судороги» (сокращенно - ХиС). В принципе этот класс, на мой взгляд, тождественен ответу «не знаю». Может ответ «не знаю» дали исполнители? Поэтому я построил еще одну диаграмму – где учтены мнения только тех, кто считает себя руководителем.
Судя по итогам моего опроса, оказывается, что почти треть руководителей даже не представляют принципов, по которым они управляют своими проектами.
По результатам своих исследований Standish Group выделяет четыре отдельных периода эволюции разработки программного обеспечения. Первый период, который длился примерно с 1960 по 1980 годы, называется «Дикий Запад». Период каскадной разработки длился примерно с 1980 по 2000 год. Период Agile начался примерно в 2000 году, и, по прогнозам Standish Group, он скоро закончится. Сейчас наблюдается начало этапа, который Standish Group называет периодом бесконечного потока, и предполагает, что этот период продлится как минимум 20 лет. В период потока не будет бюджетов проектов, планов проектов, руководителей проектов или SCRUM-мастеров. Будет бюджет для конвейера, который представляет собой чистую прямую стоимость продукции. Также потребуются затраты на управление конвейером, что снизит текущие накладные расходы по проекту на целых 90%. Это будет достигнуто за счет сокращения и устранения большей части текущих действий по управлению проектом. Функциональное описание работ будет поступать в конвейер и выходить из него в полностью пригодном для использования виде. Изменения будут происходить постоянно, но небольшими порциями, чтобы всё оставалось актуальным, полезным и более приемлемым для пользователей, а не шокировало их результатом «большого взрыва».
Эти выводы удивительным образом совпали с тем подходом, который мы восьмой год культивируем на наших проектах. Когда я публиковал первые результаты применения этого подхода на Хабр, мне казалось читатели «забросают меня валенками» и популярно разъяснят мне, что я придумал очередной велосипед. Однако со временем все больше признаков говорит о появлении новой методологии управления программными проектами, носящей существенные отличия от существующих на рынке. Например, за прошедшее время, унификация разработанных нами инструментов позволила использовать их для управления несколькими совершенно разными программными проектами. Хотя, увы, я не могу сказать, что эта методология широко применяется в ЛАНИТ, но тем не менее в нашем департаменте разработки программного обеспечения на текущий момент этот подход был апробирован более чем в тридцати программных проектах. Без физического и административного насилия над руководителями и исполнителями этих проектов. Собственно организация опроса была направлена на поиск «дыр» и способов улучшения этой методологии. Более подробно об основных принципах и результатах применения этого подхода вы можете посмотреть здесь. Для тех кто не любит читать, мы даже запилили небольшой видос. Ваше мнение действительно ОЧЕНЬ ВАЖНО для нас! Поглумитесь как следует!
Открытый вопрос
Кстати, на мой взгляд, одна из нерешенных задач, которая остается в тени, является оценка качества управления проектами на основе данных, которые собираются автоматизированными системами управления проектами. Все холивары о том, как измерить эффективность исполнителей и команд, но никто не обсуждает как измерить в ходе проекта эффективность руководителя. Не так давно, в одном из каналов, посвященных обсуждению проблем управления проектами, я пытался задать вопрос: «Какими формальными (т.е. объективными) показателями вы измеряете это самое качество управления?» Другими словами, КАК на основании данных Jira (или другого инструмента) оценить качество работы не исполнителей, а руководителей (в моменте, оперативно, до того, как проект накроется медным тазом). Может, вы знаете систему управления (плагины/дашборды), которая позволяет решить такую задачку? Однако мои вопросы остались без ответа. Совсем. Может удастся обсудить этот вопрос в комментариях к этой статье? А вдруг кто-то знает ответ?
А может, я ошибаюсь в выводах представленных в этой статье? Буду благодарен, если читатели наставят меня на путь истинный в комментариях и актуализируют сведения в опросе о применяемых системах управления проектами.