Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.
О
- управлении потоком задач на разработку,
Как избавится от «дурацких» задач? - управлении расходами на разработку,
Как определить и выбрать самые выгодные задачи? - распределении ограниченных ресурсов.
Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?
Суть проблемы и её причины
Кратко о компании, чтобы обозначить контекст ситуации. По типу деятельности — Регулятор рынка ипотечного кредитования. Отрасль — Финансы. Масштаб — Федеральный. Партнерская сеть от Владивостока до Калининграда с организацией взаимодействия с Партнерами через ИТ-системы компании. Направление работы ИТ — разработка и доработка собственных корпоративных информационных систем, поддерживающих бизнес-процессы как внутри Компании, так и на стороне Партнеров. Бюджет на развитие КИС — 100 млн.рублей в год. КИС поддерживает бизнес объемом в 60 млрд.рублей в год. Количество пользователей КИС — >2000 человек.
На момент моего прихода в компанию ситуация выглядела так, что Департамент ИТ давно утонул в потоке задач на автоматизацию бизнес-процессов и доработку тех, что уже покрыты ИТ-решениями.
Основная жалоба Заказчиков (внутренних Бизнес-Подразделений) – ДИТ работает неэффективно и не делает то, что просят.Заказчики при этом апеллируют к цифрам что за квартал из 40 запросов сделано всего 5. И так по каждому заказчику: бухгалтерии, финансовому, юридическому департаменту, департаменту покупки закладных….
Поработав некоторое время я уже воспринимал эту ситуацию лично. Ты стараешься сделать что-то хорошее и сделать это хорошо для своего Заказчика, но в конечном итоге ты всё равно плохой для него.
Это та ситуация, когда быть результативным руководителем проектов и «деливерить» недостаточно.
Причины большого потока задач:
- Объем выделенного бюджета на развитие КИС позволяет многое реализовать в ней.
- Большое количество локальных решений на основе Excel и Access на отказ от которых задано направление развития КИС.
- Пользователи и Заказчики, привыкшие к тому, что каждый запрос реализуется.
- Сотрудники ДИТ, привыкшие к тому, что всё равно что делать, что попросят то и сделают.
На рисунке морально-психологическое состояние директора ДИТ при изучении списка запросов из которых он должен выбрать те, что мы будем делать.
Шаг №1: Введение Технико-Экономического Обоснования для ИТ-запросов
Начали мы с того что ввели ТЭО для запрашиваемых разработок / доработок и внедрений ИТ-решений.
ТЭО состояло из оценки трудоемкости реализации задачи и ожидаемого экономического эффекта. Трудоемкость реализации предоставлял ДИТ, оценку экономического эффекта — Заказчик. Обоснование показало какие задачи способны себя окупить и за какой период.
Проблема: У части Партнеров сотрудники, оформляющие кредитные договора, не имеют доступа в интернет (внутренняя политика банков), по этой причине существует лаг между выходом нового шаблона договора и получением его сотрудниками, это приводит к использованию устаревших шаблонов и оформлению дополнительных соглашений к заключенным кредитным договорам.
Иногда случается, что сотрудники Партнеров вносят изменения в шаблон кредитного договора, что приводит к необходимости проверять формулировки кредитного договора на соответствие эталонным, и если они не соответствует, проводить анализ внесенных изменений и необходимых действий.
Цель: Сократить время, затрачиваемое Экспертом, на проверку Кредитного договора засчет реализации проверки кредитного договора Корпоративной ИС.
Технологическое решение:
Использовать ИТ-решение компании ABBYY (Сервис) по распознаванию документа и сверке с эталоном.
В КИС необходимо:
- Реализовать механизм передачи в Сервис сканированной копии кредитного договора и соответствующего ему эталона;
- Реализовать механизм обработки от Сервиса распознанного документа и результатов сверки.
Оценка трудоемкости реализации: 1 300 000 рублей.
Ожидаемый экономический эффект: Сокращение времени на вычитку кредитного договора (около 15 страниц), проверки соответствия шаблону и наличия изменений с 20 минут до 5. Средний ежемесячный поток кредитных договоров 3 500 штук. Час работы Эксперта стоит 523 рубля. Ожидаемая экономия = (15 минут * 3 500 КД) / 60 минут * 523 рубля = 457 625 рублей в месяц.
Срок окупаемости: 1 300 000 / 457 625 = 2,8 месяца.
Срок реализации: 3 месяца с момента направления в работу / на реализацию.
По предложению ДИТ, Руководство Компании и Бизнес-Подразделений решило, что Компания не тратит ресурсы/бюджет на задачи, где отсутствует экономическая выгода. Если решение задачи способно принести Компании существенную не экономическую выгоду, то это должно быть прописано в обосновании и на этом заострено внимание Управляющего Комитета, который авторизует данные запросы.
Так как в КИС работали и сотрудники Партнеров, мы считали экономический эффект от реализации задач и для них. Для Компании прямой экономической выгоды здесь могло и не быть, но таким образом мы повышали привлекательность и выгодность сотрудничества с Компанией. Мы делали доработку на «1 рубль», а экономический эффект от неё получали все 200 Партнеров.
Указанное решение привело к тому, что свело на «нет» огромный поток запросов с мелкими и «дурацкими» доработками, которые не приносили добавочной стоимости, но расходовали ресурсы.
Период, когда сотрудники пытались автоматизировать всё что могло быть автоматизировано, чтобы ничего не делать руками, закончился.
ТЭО привело ситуацию к тому, что теперь ресурсы ДИТ были сосредоточены на самых выгодных для компании задачах и проектах. Оно решило первую часть проблемы, теперь ресурсы использовались эффективно. Оставалась вторая — Заказчики по прежнему были не довольны тем, что ДИТ не делал то, что просят.
На рисунке изменение в лучшую сторону морально-психологического состояния директора ДИТ при выборе запросов на реализацию.
Шаг №2: Выделение ИТ-бюджета на каждого Заказчика
Каждому Бизнес-Подразделению устанавливались на год показатели (KPI), которых оно должно достичь. Для достижения этих показателей Бизнес-Подразделения порождали запросы в ДИТ на предоставление необходимых ИТ-решений. Ситуация с ТЭО привела к тому, что задачи зарабатывающих подразделений получали больше ресурсов, а обслуживающие (тратящие) подразделения оказались на положении «бедных» родственников.
У первых проекты были направлены на то, чтобы больше зарабатывать, а у вторых на то, чтобы сэкономить. Экономить/повышать эффективность собственной работы было менее выгодно, чем придумывать решения о том как зарабатывать больше. Обусловлено это было тем, что
Так как ДИТ принимал решение о том какие задачи реализовывать и куда направлять бюджет, это породило обвинения в адрес ДИТ, что мы игнорируем задачи сервисных бизнес-подразделений и отдаем предпочтение задачам зарабатывающих.
Решение пришло не сразу, так как с одной стороны всё было в порядке. Ресурсы попадают в самые выгодные для компании задачи и проекты. С другой стороны, выходит что неправильно ставить перед подразделениями показатели, которых они должны достичь, и не обеспечивать их необходимыми ресурсами для этого.
Приняли решение поделить бюджет между подразделениями в соответствии с накопленным объемом авторизованных задач. Для этого посчитали объем требуемых ресурсов на реализацию всех задач и определили долю задач каждого бизнес-подразделения в этом объеме. В этих долях «роздали» бюджет.
ДИТ по прежнему отвечал за бюджет, но теперь каждое бизнес-подразделение само решало на какие задачи, на достижение каких годовых показателей, направить выделенную ему сумму.
Так решили вторую часть проблемы, делали то, что просит Бизнес-Подразделение в рамках имеющихся у него для этого возможностей.
Что получили
- Задачи, которые целесообразно делать с точки зрения выгоды для бизнеса компании.
- Обеспечили реализацию задач и проектов каждого подразделения без необходимости сравнивать важность задач подразделений между собой.
- Предоставили Бизнес-Подразделению возможность самостоятельно решать на реализацию каких ИТ-запросов направить бюджет для достижения годовых плановых показателей.
- Планирование расходования бюджета с Бизнес-подразделением так, чтобы его хватило на год и все самые важные инициативы были реализованы.
- Возможность выходить на Бюджетный Комитет с предложением по увеличению ИТ-бюджета компании подкрепленным перечнем задач Бизнес-Подразделений с положительным ТЭО, которые не были реализованы в прошлом году в виду недостатка бюджета.
На рисунке “Happy End”.
Послесловие
ТЭО Бизнес-Подразделениям было не нужно, они в нем не были заинтересованы.
Во-первых — они хотели всё что просят.
Во-вторых — получаемый экономический эффект потом проверят.
За то ТЭО было понятно и нужно Руководству Компании, поэтому этот инструмент внедрялся по решению «сверху».
На то, чтобы научить Бизнес-Подразделения формировать внятное ТЭО ушел не один год.
Деление бюджета между бизнес-подразделениями повлекло проведение организационных изменений внутри ДИТ. Каждое бизнес-подразделение было закреплено за конкретным Руководителем Проектов. В последствии введена позиция Руководителя Направления. В зону её ответственности вошли управление бюджетом и портфелем проектных и не проектных ИТ-запросов бизнес-подразделения.
Что почитать по теме
- Стратегии формирования портфеля заказов на предприятии, выпускающем продукцию под заказ
- Оптимизация работы веб-студии. Применение теории ограничений в производстве сайтов
- Применение Теории Ограничений Систем для постановки процесса
Поделитесь в комментариях своими «кейсами» и ссылками на известные вам истории по теме. Этим вы поможете мне собрать, а другим читателям получить обзор практики.
Если после прочтения статьи у вас возникло желание потревожить мою карму Минусом, то оставьте ниже комментарий к нему, что в статье и моей личности вас задело и не понравилось. Учту вашу позицию и мнение в будущем.
Комментарии (36)
acmnu
07.11.2016 12:48+5Скорее всего, на нижнем уровне при таком подходе начинается саботаж новых продуктов и все возвращается обратно в Exсel.
Из моего опыта лучшее решение, это отправить программистов на неделю в бухгалтерию и заставить их пользоваться своими творениями. Обычно после этого у них на многие «ненужные» задачи внезапно появляется другой взгляд.
shurupkirov
07.11.2016 13:33у автора речь не идет о том, что программист делает что-то плохо, а о том, что большая часть "хотелок" пользователей экономически нецелесообразна с точки зрения прибыли компании
acmnu
07.11.2016 13:49+4Я немного не о том. Тети в бухгалтерии не будут думать о целесообразности. Они просто вернутся к привычным и работающим инструметам (вплоть до калькуляторов), а фичи, добавляемые в продукт и одобреные десятком вицепризедентов, использоваться не будут. Т.е. при таком подходе мы наталкиваемся на типичную проблему, когда ДИТ делает на бумаге все очень круто, но на деле занимается совершенно бесполезной работой. Подобный собатаж на мой взгляд самый большой головняк в больших компаниях. И единственное рабочее решение которое я знаю, это иметь своего человека среди целевой аудитории или отрправлять туда программистов на искупление.
shurupkirov
07.11.2016 14:20такие вещи решать надо только сверху, саботаж надо сразу брать за рога. я 9 лет наблюдаю описанные в сабже проблемы и саботаж. И это реально потерянные финансы компании.
acmnu
07.11.2016 17:07С таким подходом можно влипнуть в типичные проблемы иерархических систем: задержки управлющих сигналов, показуха, неэффективность. Ну не может начальник ДИТ и другой начальник решить насколько нужна какая-нибудь формочка или отчет. Они слишком высоко стоят в иерархии. Когда они пытаются на это отвлекаться, то либо не успевают, либо увязают в бюрократии.
Для эффективной разработки очень нужны горизонтальные связи с заказщиком (внутренним или внешним).
Locolind
07.11.2016 17:19+1С таким подходом можно влипнуть в типичные проблемы иерархических систем: задержки управлющих сигналов, показуха, неэффективность.
Вы правы, мы столкнулись с торможением и пошли по пути который вы предложили.
Выглядел он в двух словах так:
- Задачи стоимостью до 500 тысяч рублей согласовывает Начальник отдела.
- От 500 тысяч до 1 млн. рублей заместитель директора департамента, заказывающего бизнес-подразделения.
- От 1 млн. рублей до 3 млн.рублей директор департамента.
- Свыше 3 млн. рублей контроль на уровне заместителей генерального директора, курирующих бизнес-блок.
Заместителю генерального директора некогда и неинтересно согласовывать доработку формочки за 100 000 рублей.
Если есть ТЭО и оно говорит, что её выгодно дорабатывать, ему этого достаточно.
То что выгода будет достигнута, проверит Внутренний Аудит.
Если не будет достигнута, Заказчика наказать не накажут, но проверят окупится ли хотя бы и возьмут на заметку.acmnu
07.11.2016 17:23А что делать с задачами стоящими, скажем 1000 рублей каждая, но которых, скажем 1000 в бэклоге? Обычно такие мелкие задачи составляют основной процент работы каждого программиста.
Locolind
07.11.2016 17:28Группировать по заказчикам и/или объектам, которые требуется доработать.
А далее как в приведенном комментарии
https://habrahabr.ru/post/314448/#comment_9897288
Можно не кидаться делать эти мелкие задачи сразу, как только они возникнут, а собрать в «пачку», сделать ТЭО для «пачки» и уже принимать решение на основе дроби Эффективность/Затраты.
acmnu
07.11.2016 17:40И опять упераемся в задержки. Между релизом продукта, собиранием пачки, написанием ТЭО на пачку и собственно её отработкой пройдет существенный срок, за который можно и экспертизу растерять и дизлайк получить от бизнеса.
Locolind
07.11.2016 17:57Каждый тратит свои деньги так как считает нужным. Статья о том, как деньги считать и вкладывать с отдачей.
Если денег много, можно всю 1000 задач по 1000 рублей сделать, за этим прилетит ещё 1000 по 1000, из которых 500 будет переделать то, что сделали раньше, либо чтобы вернуть как было либо потому что надо по другому.
Но в целом ваш вариант вполне рабочий, посадили программиста со знанием предметной области в «песочницу» и там он с Заказчиком что-то лепит.
Если нужны какие-то сквозные изменения затрагивающие работу нескольких подразделений, ваш вариант потребует усложнений и изменения «архитектуры» системы, при этом в последующем ваш программист не может менять тот «кирпич», который у него отмечен, что им пользуется соседнее подразделение.
Для этого придется с ним договорится об изменениях в нём.
дизлайк получить от бизнеса
Когда денег в компании станет меньше, а привычка получать от ИТ всё что хочется останется, у вас начнет бэк-лог увеличиваться, а вот новых ресурсов вам не дадут, так как денег нет в компании.
Вы и придёте к описанной ситуации, что вы делаете что-то полезное для бизнеса, а вам говорят что этого мало и медленном, получите дизлайки от бизнеса.
Что что-то нужно менять.
shurupkirov
07.11.2016 18:35+1знаете, такой подход все равно будет в сотни раз выгоднее компании. у нас куча внутреннего ПО, которое обслуживают десять программистов, срок по перспективным задачам от 3 месяцев и в года. программы на фокспро, тягающие файловые БД, акцесс, дельфи и прочий зоопарк.
DmitryMironov
07.11.2016 14:53+2«Тети в бухгалтерии» тоже привыкают думать перед тем как что-то запросить, если это надо как-то аргументировать, кроме «мне надо и ОЧЕНЬ срочно».
По факту в большинстве случаев оказывается, что:
— надо автомизировать подготовку отчета, который нужен один раз в год,
— если все таки ДИТ это сделал, и прпросил проверить (протестировать) — сразу получаем ответ: у меня нет времени. и к этой задаче больше никогда не возвращаются.
Если есть задача, которая реально нужна — можно нормально агруменировать, а не «вернутся к привычным и работающим инструметам (вплоть до калькуляторов)».acmnu
07.11.2016 16:01Да черт возьми, иногда надо автоматизировать отчет, который нужен раз в год. Переодические отчеты, в то числе годовые могут отнимать чудовищное количество времени у бухгалтера и их сведение это одна из важнейших операций.
В этом и беда: IT совсем не понимают как работает бухгалтерия, которую они пытаются автоматизировать.Locolind
07.11.2016 16:23В этом и беда: IT совсем не понимают как работает бухгалтерия, которую они пытаются автоматизировать
Если развивать мысль, то ИТ нужно будет отправить и в продажи и в маркетинг и в логистику… во все бизнес-подразделения понимать как они работают и какие операции какой сложностью и трудоемкостью обладают.
Мне хочется уберечь Разработчиков от этих «душевных травм и драм» и отправлять в бизнес-подразделения Бизнес-аналитиков, чтобы они делили боль Заказчиков из бизнес-подразделений.
Переодические отчеты, в то числе годовые могут отнимать чудовищное количество времени у бухгалтера и их сведение это одна из важнейших операций.
Не поспоришь, всё что отнимает чудовищное количество времени у сотрудников нужно изучать и думать можем ли мы эти затраты уменьшить.
И делать это не только из чувства сострадания бухгалтеру, но и потому что это выгодно.acmnu
07.11.2016 17:02Ну если коротко, то да, я считаю что программист должен разбираться в той сфере в которой пытается действовать, иначе его эффективность сильно падает.
Всегда дешевле иметь одного спеца бухгалтер+1C, который подчиняется начальнику бухгалтерии, чем по отдельности бизнесаналитик, начальник ДИТ, чистый программист. Задержки в этой цепочке слишком велики, а в наше время решают не технологии а скорость их внедрения. Да и экономия от увольнения двух лишних в цепочке людей будет существенной, даже с учетом более высокой стоимости квалифицированного человека и неизбежного дубляжа позиций в разных отделах.
tearexs
07.11.2016 18:12+2Часто проблема автоматизации отчета, который нужен раз в год в том, что на следующий год он уже другой. Особенно если он спущен сверху.
onegreyonewhite
08.11.2016 03:25+1который нужен раз в год в том, что на следующий год он уже другой
Иногда реально выгоднее, чтобы какой-то отчёт формировали сами бухгалтера в Excel, нежели потратить ресурсы ИТ на вникание в детали задачи, доработку, тестирование и релиз. Если это будет использоваться всего раз, то нет и смысла это автоматизировать. В противном случае это двойная работа.
Всегда дешевле иметь одного спеца бухгалтер+1C, который подчиняется начальнику бухгалтерии, чем по отдельности бизнесаналитик, начальник ДИТ, чистый программист.
Во-первых, вы переходите от общего к частному. Компания в которой один программист способен справиться со всем потоком задач всей организации действительно выгодно иметь такую структуру. Но даже в статье рассматривался пример, когда программистов должно быть больше.
Во-вторых, очень тяжело и дорого быть спецом сразу в двух направлениях. Зачастую у программист+бухгалтера страдают оба направления. Программист должен знать предметную область настолько, насколько ему необходимо для решения задачи. Поэтому даже в статье приведён пример, когда сотрудники ИТ закреплены за определёнными направлениями.
Сам сталкивался с ситуацией, когда работал в сфере ЖКХ. Хотя были предоставлены все необходимые инструменты реально влияющие на бизнес, бухгалтера по прежнему в упор не хотели их использовать. Тогда я убедился, что проблемы были на 90% из-за лени бухгалтерии (ещё 10% это отсутствие финансирования и большие задержки зп).
Собственно поэтому та компания и развалилась. Они просто не смогли конкурировать.
DmitryMironov
08.11.2016 10:41Да черт возьми, иногда надо автоматизировать отчет, который нужен раз в год. Переодические отчеты, в то числе годовые могут отнимать чудовищное количество времени у бухгалтера и их сведение это одна из важнейших операций
Так никто не спорит, что это возможно надо сделать. Просто для того, чтобы это было сделано, бухгалтеру надо описать как это делается чейчас, сколько времени на это уходит, почему это важно и т.д.
И уже решение будет приниматься на основании указанных данных, а не на эмоциях и громкости голоса.
Locolind
07.11.2016 15:13+1Скорее всего, на нижнем уровне при таком подходе начинается саботаж новых продуктов и все возвращается обратно в Exсel.
Личное наблюдение.
Там где начинается саботаж новых продуктов, эти компании начинают проигрывать конкурентную борьбу. Вопрос в том на сколько хватит прочности у организации.
Там где в компаниях экспериментируют и пробуют что-то новое, случаются и инсайты и кратный рост эффективности, работать и интересно и платят хорошо, так как есть из чего платить.
Из моего опыта лучшее решение, это отправить программистов на неделю в бухгалтерию и заставить их пользоваться своими творениями. Обычно после этого у них на многие «ненужные» задачи внезапно появляется другой взгляд.
Похоже на то, что программисты получают новую квалификацию «Бизнес-аналитиков» и для них задачи перестают быть «обезличенными», они понимают для кого и что они делают, удобно ли этим пользоваться и есть ли эффект.
Ваш посыл мне в целом понятен.
Добавил бы что «рыба гниёт с головы», но часто не в наших силах заменить Руководителя в подразделении.
В моем случае это сводилось к тому, что я начинал выбирать «вменяемых» внутренних Заказчиков, которым была нужна возможность. Работа с ними, со временем, начинает отрезвлять окружающую обстановку и подтягиваются другие адекватные заинтересованные лица.
vyatsek
07.11.2016 13:46+1Прочитал по диагонали, в целом годный подход.
Тут нужен очень и очень матерый продукт оунер, у которого хватит сил и опыта послать тех, чьи задачи решают узкие кейсы за большие деньги.
Следовать подходу, кто платит, тот и заказывает музыку, но опять таки надо учитывать цели и перспективы развития системы, т.е. прямое распределение реализованных задач по бюджету может быть не до конца верным.
pa1
07.11.2016 13:48+1Спасибо за статью, даже баззовые вещи надо постоянно повторять, что бы никогда про них не забывать :).
На практике в итоге все упирается в руководство — если руководитель компании понимает, что это надо делать, то все будет хорошо. Если нет — помочь нечем, только посочувствовать руководителю ИТ, рано или поздно его съедят и пользователи уйдут в режим «мы ничего не сделали т.к. ИТ во всем виновато». И помочь ИТ руководителю в принципе нечем, увы. Чем заканчивается потом тоже могу рассказать, но это уже не так интересно.
Кстати, для небольших контор или в случае большого потока мелких задач делаем комитет (обязательно должен входить руководитель стоящий выше директоров департаментов и принимающий решение в случае споров) и планируем работы на комитете с горизонтом 1-2 недели.
ТЭО делается только на проекты в числе прочей документации.
P.S. Кстати, вы извините, но пример ТЭО некорректный — классический пример манипулирования цифрами. Хуже только «повышение прозрачности» и прочая демагогия. Мне в свое время повезло с руководителем возглавляющим комитет, на эти часы экономии он брал блокнот и говорил, «отлично, после реализации сколько человек сокращаем в вашем отделе?». А на чудо-проекты от коммерсов спрашивал «на сколько миллионов увеличиваем план продаж?». Т.е. ТЭО должен выражаться в конкретных цифрах прибыли или экономии, остальным манипулировать может даже ребенок.Locolind
07.11.2016 14:40Кстати, вы извините, но пример ТЭО некорректный — классический пример манипулирования цифрами. Хуже только «повышение прозрачности» и прочая демагогия.
Вы меня ничуть не задели и у нас не просто спрашивали сколько человек сокращаем, а пытались сокращать.
И если сотрудников не сокращали, то спрашивали куда ушла экономия.
В результате это стало сильным мотиватором для бизнеса начать использовать JIRA в своей работе, чтобы ответ на этот вопрос был прозрачен / оцифрован.
Если в компании никто не проверяет достигнут ли был результат, то вы правы люди только научаться манипулировать цифрами и уметь с их помощью обосновывать свои задачи.
Это уже полшага вперёд.
Здесь есть два варианта, что будет дальше. Мы использовали оба.
Первый — Руководство перестало давать ресурсы подразделениям на прямую. То есть для достижения увеличившихся показателей вы не можете получить ещё людей, ищите возможность повысить внутреннюю эффективность.
Например, нужно сделать уже не 10 продаж, а 20. Простой вариант, нанять ещё продавцов, а сложный это работать с воронкой продаж, конверсией и что-то оптимизировать в своей текущей работе, чтобы это время на работу с воронкой продаж и конверсией появилось.
Второй — у нас Внутренний Аудит получил новое поле для своей работы. Замерять «до» и «после».
Где-то справлялись хорошо и без него, где-то он учил руководителей считать и замерять.
DoctorNo
07.11.2016 13:48+2Все бы хорошо, но как быть с тем фактом, что расчет эффективности и реально полученная в итоге эффективность это вещи очень плохо связанные.
Ну вот возьмем ситуацию. Приходит задача нужно срочно прикрутить супер пупер фичу к продукту, после чего его продажи обещают взлетят на 10%. Расчетный экономический эффект запредельный. Задача вырывается в топы и отжирает ресурсы. В итоге никакого реального эффекта нет, колебания продаж находятся в пределах статистической погрешности.
В итоге речь идет о состязании фейковых эффектов за ресурсы ИТ. Все все равно остаются недовольными.
Дефицит он и есть дефицит какие бы правила его распределения не придумывались все равно они не будут удовлетворять учестников процесса. Будут находится ушлые — те кто по блату или обманом будут получать ресурсы и терпилы — те кто пытается играть по честному.
Решение кроется в одном. Нужно устранять проблему «дефицит ресурсов против перепроизводства задач».onegreyonewhite
08.11.2016 03:56+1Ну вот возьмем ситуацию. Приходит задача нужно срочно прикрутить супер пупер фичу к продукту, после чего его продажи обещают взлетят на 10%. Расчетный экономический эффект запредельный. Задача вырывается в топы и отжирает ресурсы. В итоге никакого реального эффекта нет, колебания продаж находятся в пределах статистической погрешности.
Тогда вопросы будут к тем, кто рассчитывал и заказывал задачу, а не к ИТ. Если эффекта нет, то либо ТЭО было неправильно рассчитано, либо появились обстоятельства, на которые решение данной задачи никак не могло повлиять (общее падение спроса/продаж, деградация «продажников» и т.п.). Бороться средствами ИТ с такими проблемами, всё равно что пытаться остановить торнадо usb-вентилятором: глупо, но научит отделы при рассчёте пытаться оценить и будущую ситуацию.
Будут находится ушлые — те кто по блату или обманом будут получать ресурсы и терпилы — те кто пытается играть по честному.
Такой подход так или иначе вредит организации и с ним нужно бороться даже когда в компании деньги самосвалом выгребают. Шаги описанные в статье лишь повод организационно и культурно обосновать «посыл».
gorodock
08.11.2016 10:14+1Большое спасибо автору за интересную статью. Изложено без лишних подробностей, просто и понятно, без уклонения в лирику. Тема близка и понятна лично мне, считаю что автор прав.
Хочется отметить благородные но неэффективные порывы некоторых комментаторов:
1. Стараться выполнить все запросы от бизнеса — крайне неэффективная мера, так как в компании, численность которой превышает хотя бы 1000 человек, в России запросы на разработку инструментов автоматизации очень часто используются не только и не столько как реальный способ улучшить свою деятельность, сколько для перекладывания ответственности за свои недоработки на плечи других служб, в частности на службу ИТ. Отсюда и саботаж и намеренное игнорирование инструментария, чуть ли не под лозунгом «я бухгалтер/кадровик/инженер… с 20/30/100 летним стажем, я не обязан(а) разбираться в ваших компьютерах, вы должны это делать за меня, а я буду как умею» и постоянный футбол и многое другое. Такие проблемы решаются не силами ИТ а организационно, на уровне руководства организации.
2. Анализировать запросы пользователей силами ИТ-специалистов «сидящих» на различных уровнях иерархии, пытаться силами ИТ оценивать «реальный» выхлоп каждого запроса, или (страшно сказать) посадить ИТ-специалистов в бухгалтерию и другие службы, чтобы видели реальную ситуацию «на фронте» — можно любую идею довести до абсурда, посадить взамен бухгалтеров и других сотрудников «с фронта» в ИТ, чтоб тоже прочувствовали, каково это исполнять все все их копеечные запросы, прерываясь параллельно на десятки звонков их же коллег с вопросами «ну тебе же это 5 минут» и т.д.
Всё таки, работа в крупной компании, требует жёсткого подхода к управлению задачами и планированию ресурсов.
Ivan22
08.11.2016 10:17Отличное ноухау.
Кстати предлагаю шаг вперед — брать задачи не только от внутренних подразделений, но и от внешних!!!
miksoft
А как быть, если есть большое множество мелких задач, не делать которые нельзя, но введение «Технико-Экономического Обоснования» настолько повысит их стоимость (это же тоже не бесплатный процесс), что они станут невыгодными?
Locolind
Ответ кроется вот в этом противоречии
, ноЕсли после составления ТЭО задачу становится не выгодно делать, то ее уже можно не делать.
Цель ТЭО — остановить поток таких мелких, которых делать нельзя, задач так как польза для компании от них либо минимальна либо вообще никакой, если они даже затрат на составление ТЭО не окупают. И сосредоточить имеющиеся ресурсы на тех задачах, которые будут приносить максимальную отдачу для Компании и Клиентов.
Пример.
Задача №1. Сделать поле №1.
Задача №2. Сделать поле №3.
Задача №3. Сделать поле №4.
Под каждое подведено основание Пользователем, всё точно нужно.
Делаем оценку трудоемкости реализации каждой.
Вот тут я вам не предлагаю разрабатывать полноценное ТЗ, здесь достаточно попытаться продумать логику как это будет работать из чего состоять и сколько времени уйдет на создание или адаптацию имеющегося под задачу.
Этой приблизительной оценки уже достаточно, чтобы посчитать экономику.
После составления ТЗ, если оно будет делаться, расчет экономики можно будет уточнить.
Сделав оценку получаем:
Задача №1 — 2 дня разработки.
Задача №2 — 2 дня.
Задача №3 — 12 дней.
Чаще всего возникает желание взяться за то, что требует меньше затрат на реализацию.
Даже если мы ошиблись в оценке трудоемкости, то затраты вместо 2-х дней составят 3 или 4.
Но в целом результат будет предоставлен быстро.
Возникает впечатление, что мы молодцы и «делевирим» то что нужно Пользователю, Заказчику.
Теперь внесем сюда оценку экономического эффекта, Пользу, которую получит Заказчик.
Чаще всего польза «сидит» либо в той операции в которой она используется или предшествует.
Как в примере выше про обработку сканкопии документа, если читать затраты 20 минут, если автоматически распознавать и сверять — 5 минут. Результат на выходе тот же, но ресурсов теперь требуется меньше.
Сделали оценку пользы:
Задача №1 — 0 рублей. (так как по задаче нужно было кнопку сделать из синенькой красненькой)
Задача №2 — экономия 1 день сотрудника в год.
Задача №3 — экономия 30 дней сотрудников в год.
Становится видно, что первые две задачи, как бы не были убедительны и настойчивы пользователи делать не надо. А ресурсы надо сосредоточить на 3-ей задаче, возможно, её стоить разбить на несколько этапов чтобы предоставить первый прототип решения Пользователю не через две недели, а через неделю.
Так мы внесем нужные правки в решение и вероятней всего впишемся в свою оценку трудоемкости или минимизируем отклонение от неё.
И последнее, Разработчику может быть и понятно зачем та или иная функция/доработка Пользователю, но вот выяснять оцифровывать Пользу это не его задача, вариантов про КТО это должен делать несколько.
Начинаются они от Team-lead-а.
Если этого не делать, мы чаще будем «жечь» дефицитные и дорогостоящие ресурсы разработки в пустую, чем создавать что-то реально ценное.
Locolind
Лучше потратить полрубля на ТЭО и не делать задачу, чем тратить два рубля на её реализацию.
Это уже экономия для компании 1,5 рублей.
miksoft
Если говорить на этом примере, то у нас считается, что тогда лучше ТЭО не проводить вовсе, а выполнить произвольно выбранную четверть задач без ТЭО. Четверть всех задач лучше, чем ни одной.
Уж не знаю, насколько это правильнее или неправильнее…
Locolind
Каждый тратит свои деньги так как считает нужным. Статья о том, как деньги считать и вкладывать с отдачей.
miksoft
Но от четверти выполненных задач будет хоть какая-то отдача.
А какая отдача будет от толстой пачки отрицательных ТЭО?
Locolind
Она будет скорее эмоциональная, чем экономическая.
Вам будут благодарны за то, что вы сделали, но вот сколько выгоды в рублях и есть ли она это неизвестно.
При этом будет то что можно точно замерить, это сколько времени было затрачено на их реализацию, и сколько вы должны получить в кассе предприятия.
Затраты, которые будут профинансированы из прибыли компании.
Представьте, что и Продавцы в компании будут работать также. Не оценивать привлекательность клиентов, а продавать каждому желающему по одной ручке за 1 рубль, затрачивая на это по 2-3 дня своего рабочего времени на сделку. Долго такой бизнес не протянет.
Askofen
Можно не кидаться делать эти мелкие задачи сразу, как только они возникнут, а собрать в «пачку», сделать ТЭО для «пачки» и уже принимать решение на основе дроби Эффективность/Затраты.
onegreyonewhite
Поддерживаю! Пачку задач и обосновать легче, и исполнить.
Единственным минусом будет то, что вместе с экономически обосноваными заказами могут и будут «просачиваться» необоснованные «хотелки».