Блудни старого ПМ-а из страны-бензоколонки

Не смотря на… (дополнительная часть).

Уже после написания трех частей этой статьи, захотелось, в качестве дополнения, рассмотреть еще один тип РП (все предыдущие вводные остаются): человек на аутстафе (аутсорсе). С моей точки зрения, самый неоднозначный вариант. Ответственности полные штаны, власти ровно ноль. Да, в иерархии любой компании пользующейся аутстафом, сотрудники, привлеченные таким образом, находятся в самом низу пищевой цепочки. Могут рассказывать любые байки и давать любые обещания, по факту же шансы на то, что они будут выполнены обычно никакие.

Собственно реальность выглядит в усредненном варианте примерно так: 
- Команду собирали не вы, она такая, какая есть, и менять ее никто не собирается.
- Разработчики, аналитики, тестеры заняты еще на двух, трех, пяти проектах.
- Дизайнер с архитектором вроде как и есть, но их прямое руководство считает, что ваш проект совершенно не в фокусе.
- Бюджет порезали, и готовы продолжать это увлекательное занятие и дальше.
- Скоуп раздувается по принципу “еще немного, еще чуть-чуть”, ну просто заказчик очень просил.
- Любые попытки на что-то повлиять (в лоб) приносят один и тот же результат – вам говорят: – вы менеджер, идите и разбирайтесь. От вас требуется результат, настаивайте, обеспечивайте и вообще не мешайте работать.

Получается классика жанра матричной структуры. Проекты отдельно, реальная власть (найм, увольнение, развитие, загрузка, приоритеты) отдельно. Почему так происходит тоже понятно. Если дать РП реальную власть, то любой подопечный становится слугой двух господ. Ничего хорошего из этого не выходит.


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

Выглядит как тупик и безнадега. Но на самом деле нет. Для начала, на самом-самом старте, вы должны сделать простую вещь. Договориться о следующем:

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

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

Не смотря на… (конец).

Продолжаем тему взаимоотношений РП и бизнес-анализа (начало – тут, продолжение - тут). Вводные полностью аналогичны тем, что описаны в предыдущих постах. Изменим только роль. Теперь РП работает внутри решения, сервиса или продукта. С моей точки зрения, самый стремный и тяжелый вариант.

Лапша для ушей в этой ситуации выглядит примерно так:

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

РП здесь оркестратор, который должен все собрать воедино и реализовать на практике красивый воздушный замок.

Теперь посмотрим, как это выглядит в реальности:

Продакт витает в облаках метрик и прочих Power Point. У него нет возможности и желания что-либо детализировать. В его картине мира, если решение нарисовано в презентации, то это полный синоним деплоя этого решения в прод. Аналитиков вам не раздали. Ну вот нет и все. Однако, задачи обязательно надо подхватывать самому, потому что так в компании принято. Технические координаторы, оркестраторы – это прошлый век, у нас все занимаются всем – говорит вам ваше начальство.

Разработкой занимается несколько внешних (внутренних) команды и очень важно понимать очередность, приоритет и зависимость задач, так как пайплайн вещь тонкая и, если что не так, тут же ложится.

Какая-нибудь команда обязательно сорвет сроки и ваш чудесный план релиза накроется тазом. Нужно будет быстро принимать решения о выпуске требуемых фич в урезанном варианте (если такое вообще возможно) и вообще кроить логику на коленке, так как аналитиков нет, своей команды тоже нет, а крайним все равно будете вы. Соответственно, надо брать в охапку тимлидов, архитекторов и как-то выкручиваться.

В этом варианте, РП который не очень понимает в технике, не владеет навыками аналитика и не понимает сам продукт (в том числе с позиции бизнеса) долго не проживет. Граница между продуктом и проджектом размывается до полной невидимости. И, как сказал выше, это самый сложный вариант, так как огребать придется часто и много, а вот выхлоп за труды, может быть достаточно эфемерным.  На такое можно пойти только от полной безнадеги, или, наоборот, очень четко понимая, зачем и почему вы это делаете.

Не смотря на… (середина).

Продолжаем тему взаимоотношений РП и бизнес-анализа (начало тут). Вводные аналогичны тем, что в предыдущем посте. Изменим только роль. Теперь РП работает с внешними заказчиками.

Какая лапша вешается на уши в этом случае:

Заказчик приходит с полностью вменяемыми функциональными требованиями или ТЗ, в которых описано все что можно и нельзя (процессы, интеграции, информационные потоки).

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

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

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

Никто себя случаем не узнал? Ну это я так, к слову. Теперь посмотрим, как эта красивая картинка превращается в тыкву.

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

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

Вы всеми правдами и неправдами добываете аналитика/архитектора, но этот халиф только на час (денег на большее вам никто давать не хочет), а реально требуется как минимум пара недель, а то и месяц. Единственный вариант: садится самому, возможно с чьей-то, типа СТО, помощью и, на коленке, крапать что-то. И очень быстро, так как, увы, но медицинский факт, на пре-сейл скорость решает практически все.

На основании сделанного на коленке, рождается электронная долбанина. Которую надо еще сдать клиенту. И объяснить, что вот это чудо – это ровно то, о чем договаривались и чего он хочет. То есть отдельный квест. Причем во время сдачи, никто вас не поддерживает и не может внятно объяснить, как полученное чудо работает.

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

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

Несмотря на… (начало)

Первый пост из серии на тему многолетних холиваров «Какие дополнительные навыки РП гарантируют успешный успех?». 

И сегодня речь пойдет о навыке бизнес-анализа. С одной стороны, я искренне считаю бизнес-анализ расширенным продолжением критического мышления (у кого его нет, сорян, можно дальше не читать), с другой – этот совершенно универсальный навык, аналог езды на велосипеде или коньках, буде единожды освоен, остается с человеком на всю жизнь. Я искренне полагаю, что он для РП является обязательным, несмотря на то что это явно не его основная компетенция. Давайте посмотрим на примере, как оно бывает в жизни.

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

Все функциональные требования можно получить у бизнеса.
Вы, как РП, выступаете связующим звеном между бизнесом, командой и подрядчиком, обеспечивая коммуникации и управление процессом.

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

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

Никто себя случаем не узнал? Ну это я так, к слову.  Теперь поглядим, как эта красивая картинка превращается в реальную тыкву.

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

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

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

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

А теперь добавим в ту же ситуацию использование навыков бизнес-анализа. И получим следующее:

Вы проверили (лично), что все декларируемые пожелания бизнеса описаны в функциональных требованиях и там нет конфликта, или каких-то позабытых моментов, проверили маппинг ФТ на ТЗ (чтобы случайно, а то и преднамеренно чего-то не потерять). Вы оценили вместе с бизнесом приоритет и критичность высказанных пожеланий, и донесли (закрепили на бумаге) это до исполнителя. Вы точно понимаете, как вы будете принимать выполненные работы (не обязательно это делать самостоятельно). И, вишенка на торте, вы понимаете как все сделанное будет презентоваться бизнесу в разрезе эффектов, метрик, ожиданий и т.п. Безрадостная ситуация начинает играть иными красками, не правда ли? 


Продолжение следует...

Развернись плечо, размахнись рука.

Из цикла «Записки аудитора». По традиции, опять с цифрами.

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

Кейс 1. Bus-фактор.
Я так и не понял в итоге, то ли о нем не знали, то ли считали игрушкой (Bus-фактор, в смысле), но в итоге упустили одного из СТО (на каждом продукте там был свой СТО), в итоге задержка релиза на несколько месяцев, потери в деньгах (кто-то из клиентов ушел, простои и восполнение знаний и т.п.) порядка 40 миллионов. Ну, и по традиции, свалка в документации и все сопутствующие радости. Когда-таки посчитали bus-фактор, нефинансовую мотивацию и кое-что еще, увидели риски, о которых никто не подозревал. В общем, почти хеппи-енд.

Кейс 2. Отсутствие стандартизации и хаос в постановке задачи.
Классическая ситуация, когда команда (например 12 человек, стоимость человеко/часа – 5000 руб), тратит немного времени на общение в мессенджерах на уточнения, в каком формате и что именно нужно делать (куча мелких деталей). За неделю выходит примерно по пять часов у каждого из сотрудников. В рублях, соответственно, 300 000. И это только один кейс там. Документированный процесс стоил бы им куда дешевле. Оставил несколько идей, что с этим вообще можно и нужно делать. Обещали подумать и вернуться. Посмотрим.

Кейс 3. Паралич согласований.
Об этом я писал неоднократно, но реальность, она такая реальность. Несмотря на то, что формально матрицы RICE (DICE) используются (не везде, конечно, но тем не менее), паралич согласований, особенно в аутсорсе, вещь повсеместная. Я понимаю, что нарисовать процесс и жить по нему, это две, незнакомые между собой, сущности, правда при взгляде на цифры, становиться грустно. Это дни(!) простоя. В примере выше, день простоя – 480 000 рублей. По моим личным прикидкам, если навести порядок, то 10-12% операционной эффективности на пустом месте можно выжать легко. Если конечно это кому-то надо, на самом деле.

Кейс 4. Немного не по моему основному профилю, но пусть тоже будет здесь. Боль и надежды хомячков.
Про разработку и внедрение фич, которые нахрен никому, кроме команды, не нужны и неинтересны. Ограничусь цифрами. Порядка 15% фич в продуктах клиентам не интересны от слова совсем (но клиентов заставляют за них платить). Аккуратно скажу, что до четверти всех фич в спринте, обычно появляются без обоснования какой-либо бизнес-пользы от их разработки. Бывает и больше. Если смотреть на процесс фича-реквеста, то есть несколько очень простых и показательных параметров, внедрение которых сильно улучшает статистику полезности. Но, для этого, это так же должно быть кому-то надо.

Вместо заключения: у богатых свои причуды, они могут развернуться и размахнуться на весь кошелек. Вот только, при прочих равных, как надолго их богатства то хватит – неизвестно.

Слышал звон, да вот где он?

Из цикла «Записки аудитора». Наверное даже дрозды, потихоньку вытесняющие на улицах привычных воробьев и голубей, уже знают, что процессы надо выстраивать, оптимизировать и все такое прочее. И вообще, когда процессы хорошо выстроены – хорошо всем, а когда их нет – всем плохо. Но, если с птичек больше взять особо нечего, то меня поражают человеки (разного возраста, пола, грейда и т.п.), которые к этим процессам так или иначе приставлены, но вот связно ответить, почему над процессами надо работать, увы не в состоянии. Максимум, начинают блеять про какую-то там эффективность. Когда спрашиваешь, а что, собственно, за эффективность, в чем она заключается, то либо теряются, либо начинают нести чушь. Понятное дело, что не только лишь все, но тем не менее. Картина настолько массовая, что мне даже как-то неудобно становится.

Этот пост об операционной эффективности. Той самой эффективность, которая и интересна при оптимизации процессов. Все, о чем пойдет речь ниже, справедливо лишь для тех случаев, когда в структуре издержек компании ФОТ > суммы затрат на материалы и оборудование. Если пропорции другие, логика расчетов меняется.

Для начала, несколько примеров неэффективности.

За основу расчетов возьмем параметры, которые я уже использовал в прошлых статьях: средний оклад 1 человека – 360 000 руб/мес, средний ЕСН (для ИТ компаний, для не ИТ-заметно выше) по году – 12,2%, коэффициент накладных расходов на содержание 1 сотрудника – 100% от ФОТ. Путем нехитрых подсчетов, получим реальную стоимость одного человеко-часа – 5049 руб. Вот от этого и будем отталкиваться дальше.

Пример 1. Хаотичное расположение справочных и прочих полезных материалов, которые периодически нужны в работе, известное так же как процесс документального сопровождения и обеспечения (у вас он может называться совершенно иначе, но это ничего не меняет). Для вкуса добавим немного хаоса в наименования этих материалов (не ММК_АРХ_Ревью_20_24, а Ермолаев_ММК_new) чтобы банальным поиском это было найти чуть сложнее.

Я где-то прочитал, что, в процессе поиска, один клик мышки в среднем занимает 5 секунд. В принципе, похоже на правду. А теперь магия. За час (3600 сек) можно сделать ровно 720 кликов, что в общем не гарантирует ничего, но для примера, введем ряд ограничений. Пусть, любой сотрудник (а их у нас будет, скажем, 18) три часа в неделю тратит на поиски чего-нибудь нужного. Считаем, сколько это будет стоить в месяц: 18 х 3 х 4 недели х 5049 руб = 1 090 584 руб. Нехило так, правда? И это из месяца в месяц… Навести порядок в этой части стоит крайне недорого и занимает примерно квартал.

Пример 2. Подготовка ТКП. Шаблонов, разумеется, нет (Формальное объяснение этого казуса, например такое: продукты все постоянно допиливаются, следовательно, что там будет по железу, надо смотреть в моменте, из сервисов / продуктов клиент может набрать любую конфигурацию из условных 20 позиций, и вообще, там есть зависимость от объема потребляемых данных – это реальный случай из моей практики). В процессе подготовки участвуют: технический аккаунт, сейл, пресейл, архитектор, продукт и системный аналитик по железу, большой продукт и два поменьше по сервисам, архитектор по сервисам, пара проджектов (всего 11 рыл). Цепочка согласования любых изменений: проджект (один из) → большой сервисный продукт → сейл. Согласуются любые значимые изменения. В среднем, 4-5 кругов согласований. Средняя длительность подготовки – две недели. Каждый из участников, тратил на эту активность минимум треть рабочего времени. Итого: стоимость документа – примерно полтора миллиона рублей. За короткий исторический период было подготовлено порядка 20 таких предложений. Ни одно не выстрелило.

Всем привет!

Сегодня у блога фактический день рождения, ему исполняется 2 года. С одной стороны, это конечно не возраст, с другой - достаточно длинный путь.

За эти два года, я несколько раз менял подходы к формированию контекста, вводил разные рубрики, и вообще экспериментировал от души. И наверное, не все делал неправильно, так как у блога сформировалась достаточно приличная аудитория, с учётом того, что рекламой его я не занимался вообще.

В принципе, в настоящее время, в блог идут те темы и вопросы, которые меня окружают, волнуют, интересуют и приходят в голову плюс-минус несколько недель от текущей даты (я обычно создаю определенный запас постов на несколько недель вперёд, так как увы, писать еженедельно не получается).

В общем, спасибо что читаете, комментируйте и вообще следите за блогом! Контента, если что, припасено ох как надолго)

С уважением,
Кирилл

Всем привет!
Для начала с праздником! Сегодня содержательного поста не будет! Погода летняя, хорошая, так что отдохнем))

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

Ещё один момент. В июле, временно перейду на 1 пост в неделю (по средам). Честно, перед всеми извиняюсь, но дел пока слишком много, что бы сохранить качество постов и самому себя не загнать, принял вот такое, непростое решение.
Надеюсь, что горячка схлынет и все вернется на обычные рельсы.

Я честно говоря не ожидал, что тема операционного аудита вызовет столько интереса. В этой связи (и помня мои старые планы), готовится интенсив по введению в эту тему (теория, практические кейсы, метрики, чек листы и прочая). Пока думаю уложиться в 8 часов + индивидуальные разборы личных кейсов с участниками. Это все будет за рамками блога, на отдельной платформе. Кому интересно - следите за анонсами.

Ну и в июле, 4 числа, проектные шашлыки (очный ит трындельник), тут все будет как и было обещано.

Вкратце, как-то так.

С уважением,
Кирилл

Где найти, где потерять (III).

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

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

Приведу расчет стоимости ритуалов для одного конкретного коллектива из 18 человек (тут и разработчики, и немного аналитиков, и тестировщики, и три разных менеджера).

Возьмем за основу расчетов следующие показатели:
– средний оклад 1 человека – 360 000 руб/мес,
– средний ЕСН (для ИТ компаний, для не ИТ-заметно выше) по году в размере 12,2%,
– коэффициент накладных расходов на содержание 1 сотрудника в размере 100% от ФОТ (на самом деле больше, но пусть будет так).

Путем нехитрых расчетов получим стоимость одного человеко-часа в размере 5049 руб.

Теперь перейдем к ритуалам:
– дейли – 3 шт в день на каждого сотрудника по 15 минут,
– демо – 1 раз в месяц по часу на всех,
– ретро – 2 часа 2 раза в месяц на всех,
– планирование, груминг – 2 часа 2 раза в месяц для трети коллектива.
Итого в месяц на ритуалы тратится 408 часов (из 2880 рабочих).

В примере не учитывается время на подготовку, переключение между задачами и прочие подобные вещи для упрощения расчетов. В деньгах это все дело стоит чуть больше 1,8 млн руб. Так, ерунда, всего лишь 5 месячных ставок. При том, что месячный ФОТ у нас на этот коллектив 6 480 000 руб. Чисто на ритуалы расходуется порядка 28% ФОТа. Я умышленно считаю отношение ФОТа к реальной стоимости коллектива. Пояснять почему, надеюсь не надо.

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

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

Где найти, где потерять (II).

В этой части статьи я расскажу вам о гигиене коммуникаций. Нет, речь не о токсичности и прочем подобном, а том, как беспорядочные коммуникации в большом количестве крадут время, а, соответственно, и деньги. Вторая часть примеров из моей практики – что выявляет ИТ-аудит.

Возьмем реальный проект по внедрению МДМ-системы (там же очистка данных, создание модели данных, но это не так важно), длительностью примерно в год, и общей стоимостью, пусть будет, 50 миллионов рублей (без НДС). Со стороны подрядчика, команда 10 человек, со стороны заказчика – человек 25, но, в контексте примера, ограничим ее 5 сотрудниками.

РП со стороны заказчика требует ежедневные синки на 15 минут для всей команды. Прикинем стоимость такого мероприятия. Один час работы исполнителя стоит чуть больше 26 000 рублей ((50 000 000/12)/160). Четверть – 6,5 тысяч рублей. Возьмем со стороны заказчика усредненный месячный ФОТ одного сотрудника в 360 000 рублей и, путем нехитрых расчетов, узнаем, что совокупная стоимость сотрудников заказчика на 15-минутный синк составляет – 2 800 руб. Итого, за неделю, только на этот синк тратится 46 500 руб. Вроде не много. Однако, получается, что в рамках всего проекта, только на это тратится порядка 5% бюджета. Это одна сторона медали. Другая сторона в том, что, по факту, этот синк не уложится в указанные 15 минут. Он займет больше. И большая часть людей на нем будут сидеть и просто присутствовать. И это один синк!!! Грустно как-то становится. В реальности я показал эти выкладки спонсору проекта, с вопросом, готов ли он оплачивать банкет. В итоге пришли к куда более разумному компромиссу.

Гигиена коммуникаций – это Клондайк. В ней реально зарыты миллионы. Проводя в рамках аудита исследование подобных вещей, я нахожу шок-контент, который со стороны очевиден. Организаторы всевозможных звонков примерно никогда не задумываются о реальной их стоимости. Сколько раз я видел звонки на человек 8-12 с одной стороны и 1-3 с другой. Пытался чего-то объяснять, но как об стенку горох. Сколько из этих людей реально участвует, а не просто сидит в таком звонке – вопрос в воздух. Еще пример. Совещание с названием «Совещание» на всех руководителей часика эдак на полтора. Разумеется, без повестки. Стоимость… а кого это волнует-то?

В среднем получается, что на коммуникации в синхронном режиме (а есть еще и асинхронное общение в чатах, например), производственный персонал тратит порядка 40% времени.

Что это значит в деньгах? Возьмем реальный коллектив (пример от другого заказчика) из 50 человек, со средним ежемесячным окладом в 360 000 рублей/человек, в год на такую коммуникацию уходит чуть больше 85 миллионов рублей. И это не считая времени на подготовку, переключение и прочая.

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

Где найти, где потерять (I).

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

Начнем с процессов проектного управления. Все процессы, так или иначе, описываются в виде инструкций, регламентов и прочих документов. Про основные боли, связанные с этим процессом, я уже писал пару месяцев назад. Кратко напомню:
– О документах никто не знает.
– Их не считают обязательными.
– Они не помогают (в них сложно разобраться).
– Документы устарели (не обновляются) или обновляются слишком часто.
– Нет обязательных регулярных тренингов (демо).

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

Сколько в реальности стоит разработка небольшого документа страниц на 15? В Таблице 1 (прикреплю в комментариях) приведена примерная стоимость разработки одного такого документа. Пример взят из реальной практики, для простоты изложения и понимания, используются определенные допущения, не влияющие на общий смысл.

В желтой части таблицы приведены исходные данные для расчетов. ЕСН рассчитан по действующим нормам, как средний за год для компаний, имеющих ИТ-аккредитацию.

Накладные расходы (включил сюда все что можно) составляют 200% от ФОТ (на самом деле получилось скромно, но для примера сойдет).

Итоговая цена, скажем, за 15-страничный документ выглядит относительно реалистично. В итоге одна страничка стоит 44 431 руб. Округлим вниз, до 40 000 руб.

Теперь представим, что за год, с учетом разработки новых документов, модификации, актуализации существующих и т.п., в компании производится порядка 1000 таких страничек. Стоимость работ выходит в районе 40 миллионов рублей. Если посчитать в попугаях, то это 8-10 годовых ставок достаточно квалифицированных сотрудников.

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

Всем привет! Сегодня начинается лето, и в этой связи немного мыслей о дальнейших планах блога.
1. Завтра начинается публикация цифр и расчётов стоимости потери времени на разное... цикл - записки аудитора.
2. Через полторы- две недели начнется публикация очень большого текста (5 частей в итоге) по метрикам для оценки РП. Материал получился немного скандальным и очень дискуссионным. Надеюсь увидеть огонь в комментариях.
3. В июне блогу исполнится два года. Но это отметим 4.07 на шашлыках.
4. Прошло почти полгода, как я поменял формат блога и судя по всему, изменения зашли. В этой связи у меня есть запрос к моей аудитории - что бы было интересно вам услышать в дальнейшем? Какие рубрики нравятся, что лишнее, что добавить? Ответы, пожелания, критику, жду в комментариях под этим постом. Ограничений (ну кроме нда и прочего подобного) нет. Для меня это важно. И заранее спасибо!

С уважением,
Кирилл

Что будет, то будет, была не была!

Минус деятельности проектного аудитора – заказчик частенько пытается переквалифицировать его в бизнес-консультанта, по ходу пьесы. Это, честно говоря, забавляет. Если бы у меня была волшебная таблетка, то я ее давно бы уже менял на доли в бизнесах, подлеченных ею, но увы. Ссылаться на формальный состав услуг по договору вариант так себе, что-то реально советовать – еще хуже. В итоге остановился на варианте, когда я рассказываю, как оно бывает, что я видел, но без интимных подробностей.

Есть несколько основных больших (или больных) тем. Сегодня поговорим об одной из них – оценке сроков. Тема сложная. Одно дело, когда у тебя есть понимание бюджета и всего остального от заказчика (сейл/аккаунт сработали хорошо), другое дело, когда надо, по тем или иным причинам, угадать. И тут есть развилка (считаем, что дополнительной информации добыть не удалось):

Сценарий первый. Играть один раз. Все «инициативы», прошедшие тест на жадность и разумность, берутся и оцениваются как есть. Попали в баллистику клиента, не попали – не важно. Важно другое, что, если не попали, больше в оценку (переоценку) от этого клиента до получения дополнительных вводных (если они вообще будут), не берется ничего. Иначе придется сжигать ресурсы, конкурируя с «автоматизаторами ларьков» – на рынке сейчас стоимость играет чуть ли не ключевую роль.

Сценарий второй. Есть замечательная книжка «How big things get done», Бента Флайберга и Дана Гарднера (доступен русский перевод 24 года издания). В ней, помимо прочего, авторы проанализировали много тысяч реальных проектов (в том числе и в ИТ) и пришли к следующим выводам:

– Уложились в бюджет 47,9% проектов (почти половина).
– Уложились в бюджет и сроки – 8,5% (почти один из 10).
– Ужились в бюджет, сроки и получили ожидаемый результат – 0,5% (один из 200).

Глядя на приведенную статистику, цинично понимаем, что в лучшем случае рассматриваемый проект попадет в 8,5%, сознательно «забываем» про какие-то аспекты задачи, чтобы удешевить предложение и подсадить клиента на своеобразный крючок. Это вот прям коронный стиль контор, внедряющих 1С (не всех, разумеется).

Сценарий третий. Платная оценка. Да, вы прочитали правильно, клиент платит за оценку проекта. Это может приобретать разные формы, и да, это реально. Хотя конечно, для реализации этого сценария должны сойтись звезды. В частности, должно очень хорошо отболеть у всех участников процесса, чтобы они реально перешли к конструктиву в части ценности, сложности реализации/тестирования и т.п. Что именно будет результатом платной оценки? Ну, как договоритесь.

Сценарий четвертый. Оценка вилкой. Нечасто встречающийся вариант, но мне лично он симпатичен. Как строится вилка в моем случае:

– Оценка задач «как есть». Вот что написано, то и оценено. Сколько получится.
– Оценка «минус Х%», если заказчик все-таки перезаложился, и вообще ему нужно не то, что он написал. Такое, кстати, часто бывает (но по факту – это оценка игры около нуля, интересной по имиджевым и прочим причинам).
– Оценка «плюс Y%». Заклад, с нашей стороны, на сложные интеграции, возможные флуктуации того же законодательства и, вообще, на «черных лебедей». По факту – баланс между жадностью, осторожностью, расчетливой рискованностью.
Тут еще можно красиво скоммуницировать, что все, кто дал оценку ниже п.2. – нехорошие редиски, чего-то не учитывающие, хотящие потом прокинуть на доп работы.

Вместо эпилога. Вполне очевидно, что ничего нового я не скажу, однако соль не в том. Во-первых, я не говорю «нет», и не отбрыкиваюсь от не совсем моих вопросов. Во-вторых, я ничего не советую (не беру, в данном случае, на себя ответственность). Вспоминаем разницу между терминами «услуги» и «консультации», о которой я не раз писал. Это именно «консультация». В-третьих, есть немалая вероятность, что в головах собеседников после таких разговоров, выстроится какая-то интересная корреляционная цепочка, которая им поможет… всякое бывает.

Всем привет! Ит-трындельнику на природе быть! Дата - 4.07 (суббота). Место проведения - Парк Сокольники. Время 15-00 и до вечера. Формат - шашлыки (их я готовлю лично!) желающие присоединиться, полагаю придумают способ это сделать🤣.

PS. Мероприятие не коммерческое, но платное, увы.
PSS. Только Москва и ближайшие окрестности.