Анатомия страхов на программных проектах

В январе 2022 года на Хабре была опубликована статья, в которой мной было высказано предположение, что главной причиной беспокойства, бессонницы, нервных срывов и головной боли на программных проектах являются страхи, которые преследуют сотрудников этих проектов даже, казалось бы, при внешне успешной обстановке. Для того, чтобы проверить эту гипотезу, и в поисках причин, по которым любимая работа на IT-проектах начинает вызывать отвращение, в этой же статье был запущен открытый опрос . Предвзятый и субъективный анализ результатов этого опроса вы найдете в статье ниже. Любая конструктивная и оптимистичная критика приветствуется.

По мотивам

Боитесь ли Вы молнии?

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

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

Источник

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

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

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

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

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

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

Всем известно, что рыба гниет с головы. Поэтому для проведения аттестации в Москву пригласили директоров основных предприятий отрасли. Чтобы обеспечить полную объективность и непредвзятость этой проверки, на первом этапе аттестация предполагала проведение тест-опросов на проверку когнитивных способностей и психологической устойчивости.

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

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

– Ты не знаешь, как отвечать, если вопросы какие-то дурацкие?

– А что за вопрос?

– «Боитесь ли Вы молнии?»

– Да отвечай как-нибудь. Какая разница? На производство это не влияет.

– Да мне непонятно, так это в детстве или сейчас.

– Да сейчас, конечно, сейчас.

– «Боитесь ли Вы молнии?»

– Да мне непонятно, это в детстве или сейчас? – прохрипел суровый директор.

– Да не волнуйтесь Вы так. Сейчас. Конечно, сейчас.

По мотивам

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

– «Вы когда-нибудь хотели убежать из дома?»

– Мне непонятно, это в детстве или сейчас?!

– Да сейчас. Конечно, сейчас.

То что произошло потом, по всей видимости не планировали ни организаторы этого мероприятия, ни сам виновник произошедшего, ни тем более стоявшая рядом обладательница накладных двухсантиметровых ресниц, густо обрамлявших глаза, неожиданно ставших круглыми как два светлоголубых блюдца. Услышав ответ консультанта, суровый директор, вдруг внезапно швырнув ручку на пол, вскочил со своего места красный и мокрый, как будто в лицо ему плеснули крутым кипятком. «Я оказываюсь отвечать на все эти ваши провокационные вопросы! – закричал он, вцепившись в край стола побелевшими пальцами с видом приговоренного, которого затаскивают на эшафот. - Я вообще оказываюсь принимать участие в этом мероприятии!»

Потом в курилке, обсуждая произошедшее, один из участников опроса, который был в числе первых «отличников», сдавших свою анкету, устало высказал свое мнение: «И что это Иваныч так близко к сердцу эту интермедию принял? Первый раз, что ли, ритуальные танцы танцевать? Я неделю назад, сразу после того как пришла телеграмма о этом мероприятии, направил сюда своего зама по компьютерным делам. Для обмена, так сказать, бесценным опытом. Он с местными эникейщиками быстро договорился. Два ящика коньяка – и сегодня все эти бумажки вообще без моего участия правильно заполнили. Делов-то...»

Правила фальсификации результатов

Отдельные вопросы, на которые я хотел бы получить ответы, пришли на ум и были добавлены уже гораздо позже публикации опроса. Чем, например, объясняется гораздо меньшее количество ответов на вопросы об индивидуальных планах работ и об обучении.

Чтобы излишне не пугать респондентов, вопрос, который требовал обязательного ответа, был только один: «Какая ваша роль на проекте?». Поэтому проанализировать результаты в разрезе отдельных групп ответов в полном объеме не представляется возможным ввиду отсутствия этих ответов Например, 7 участников опроса не смогли выбрать тип 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-проектах это подтверждает.

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

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

Автоматизация CHAOS

Иногда начальство ставит передо мной задачу присмотреть какую- нибудь систему управления проектами взамен Jira. Бывает даже контекстная реклама подбрасывает им руководители сами находят такую систему и просят меня оценить перспективы применения ее на наших проектах. Поэтому одной из задач, которые я ставил при проведении этого опроса, была потребность выяснить, какие инструменты наиболее эффективны популярны в непростом деле автоматизации, о чем не знают 30% руководителей программных проектаов (см. предыдущий раздел).

Хотя контакты с представителями отделов продаж этих отечественных систем вызывают у меня смутные подозрения о том, что разработчики этих систем слабо представляют, что именно они продают. Когда я общаюсь с этими представителями, обычно я задаю им один и тот же вопрос: «Убедите меня, почему я должен приобрести именно вашу систему управления проектами». Почему-то ответы представителей от разных производителей звучат как под копирку (мысли вслух):

– «Наша система полностью отвечает всем требованиям импортозамещения» (И какой профит даст мне переход с иномарки на отечественный продукт?);

– «У нашей системы очень удобный и дружелюбный интерфейс» (Да меня и текущий интерфейс вполне устраивает...);

– «Для настройки нашей системы используются более 300 параметров, и вы можете настроить ее под любой свой проект» (Господи, я скорее умру прежде, чем ее настрою...);

– «Наша система поддерживает почти все функции Jira» (Почти? Не понял, зачем мне менять Jira на мыло , если я потеряю в функциональности);

– «Наша компания предлагает очень удобные условия лицензирования» (Не понял, я кредит беру или систему управления проектами?).

Иногда эти сотрудники пытались мне рассказать о каких-то киллер-фичах своих продуктов, однако при этом не могли ответить на встречный вопрос: «Какие именно проблемы на моем проекте поможет мне решить эта киллер-функция?»

По мотивам

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

Однажды на учебных курсах по менеджменту жизнь меня свела с вице-президентом одной компании, которая недавно выпустила на рынок собственную систему управления проектами. Реклама характеризовала этот продукт не больше не меньше как «киллер Jira». Когда мы обсуждали достоинства этой новой системы, я спросил у него: «А за счет каких именно преимуществ ваша система должна «убить Jira» на рынке автоматизации управления проектами?» В качестве примера я вспомнил, какое влияние оказало появление нарезного стрелкового оружия на результаты Крымской войны середины XIX века. «Какие «нарезы» вашей системы позволят мне обойти конкурентов? – спросил я. – Только не рассказывайте мне про импортозамещение и низкую стоимость эксплуатации. Это не повод менять Toyota на Ладу-Калину». Мой визави почему-то не нашел, что мне ответить. Правда, после нашей беседы рекламу этого продукта, содержащую словосочетание «киллер Jira», я больше не встречал.

Другой показательный случай произошел со мной, когда я решил пройти собеседование на вакансию руководителя внедрения в госсекторе одной отечественной автоматизированной системы управления проектами, которая позиционировалась вендором как одна из самых эффективных на рынке РФ. Судя по информации на сайте компании, на тот момент эта система была успешно внедрена в работу более чем в трех сотнях различных организаций. Собеседование проводили несколько человек, среди которых был ведущий конструктор и один из замов генерального. Это мероприятие больше было похоже на небольшой экзамен по прикладным аспектам применения 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 год относит к числу распространенных иллюзий утверждение о том, что выбор инструмента управления определяет успешность программных проектов. И на мой взгляд, вендор, который сосредоточит усилия на внедрении методологий, а не инструментов, имеет все шансы выхода на простор нового голубого океана .

Рецепты управления

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

Вероятно, вы спросите меня что такое ХиС? С легкой руки одного из респондентов я объединил методологии «Барин и холопы», «Один за всех и все не за кого», «Чайка-менеджмент», ScrumBut в один класс «Хаос и судороги» (сокращенно - ХиС). В принципе этот класс, на мой взгляд, тождественен ответу «не знаю». Может ответ «не знаю» дали исполнители? Поэтому я построил еще одну диаграмму – только для руководителей.

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

По результатам своих исследований Standish Group выделяет четыре отдельных периода эволюции разработки программного обеспечения. Первый период, который длился примерно с 1960 по 1980 годы, называется «Дикий Запад». Период каскадной разработки длился примерно с 1980 по 2000 год. Период Agile начался примерно в 2000 году, и, по прогнозам Standish Group, он скоро закончится. Сейчас наблюдается начало этапа, который Standish Group называет периодом бесконечного потока, и предполагает, что этот период продлится как минимум 20 лет. В период потока не будет бюджетов проектов, планов проектов, руководителей проектов или SCRUM-мастеров. Будет бюджет для конвейера, который представляет собой чистую прямую стоимость продукции. Также потребуются затраты на управление конвейером, что снизит текущие накладные расходы по проекту на целых 90%. Это будет достигнуто за счет сокращения и устранения большей части текущих действий по управлению проектом. Функциональное описание работ будет поступать в конвейер и выходить из него в полностью пригодном для использования виде. Изменения будут происходить постоянно, но небольшими порциями, чтобы всё оставалось актуальным, полезным и более приемлемым для пользователей, а не шокировало их результатом «большого взрыва».

Эти выводы удивительным образом совпали с тем подходом, который мы восьмой год культивируем на наших проектах. Когда я публиковал первые результаты применения этого подхода на Хабр, мне казалось читатели «забрасают меня валенками» и популярно разъяснят мне, что я придумал очередной велосипед. Однако со временем все больше признаков говорит о появлении новой методологии управления программными проектами, носящей существенные отличия от существующих на рынке. Например, за прошедшее время, унификация разработанных нами инструментов позволила использовать их для управления несколькими совершенно разными программными проектами. Собственно организация опроса была направлена на поиск «дыр» и способов улучшения этой методологии. Более подробно об основных принципах и результатах применения этого подхода вы можете посмотреть здесь . Ваше мнение действительно ОЧЕНЬ ВАЖНО для нас! Поглумитесь как следует!

Источник

Открытый вопрос

Кстати, на мой взгляд, одна из нерешенных задач, которая остается в тени, является оценка качества управления проектами на основе данных, которые собираются автоматизированными системами управления проектами. Не так давно, в одном из каналов , посвященных обсуждению проблем управления проектами, я пытался задать вопрос: «Какими формальными (т.е. объективными) показателями вы измеряете это самое качество управления?» Другими словами, КАК на основании данных Jira (или другого инструмента) оценить качество работы не исполнителей, а руководителей (в моменте, оперативно, до того, как проект накроется медным тазом). Может, вы знаете систему управления (плагины/дашборды), которая позволяет решить такую задачку? Однако мои вопросы остались без ответа. Совсем. Может удастся обсудить этот вопрос в комментариях к этой статье? А вдруг кто-то знает ответ?

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

По мотивам