Управление задачами на разработку. История из жизни
Дурацкая задача — когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.
о:
- управлении потоком задач на разработку,
Как избавится от «дурацких» задач? - управлении расходами на разработку,
Как определить и выбрать самые выгодные задачи? - распределении ограниченных ресурсов.
Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?
Суть проблемы и её причины
Кратко о компании, чтобы обозначить контекст ситуации
По типу деятельности — Регулятор рынка ипотечного кредитования.
Отрасль — Финансы.
Масштаб — Федеральный.
Партнерская сеть от Владивостока до Калининграда с организацией взаимодействия с Партнерами через ИТ-системы компании.
Направление работы ИТ — разработка и доработка собственных корпоративных информационных систем, поддерживающих бизнес-процессы как внутри Компании, так и на стороне Партнеров.
Бюджет на развитие КИС — 100 млн.рублей в год.
КИС поддерживает бизнес объемом в 60 млрд.рублей в год.
Количество пользователей КИС — > 2000 человек.
На момент моего прихода в компанию ситуация выглядела так, что Департамент ИТ давно утонул в потоке задач на автоматизацию бизнес-процессов и доработку тех, что уже покрыты ИТ-решениями.
Основная жалоба Заказчиков (внутренних Бизнес-Подразделений) — ДИТ работает неэффективно и не делает то, что просят.Заказчики при этом апеллируют к цифрам что за квартал из 40 запросов сделано всего 5. И так по каждому заказчику: бухгалтерии, финансовому, юридическому департаменту, департаменту покупки закладных….
Поработав некоторое время я уже воспринимал эту ситуацию лично. Ты стараешься сделать что-то хорошее и сделать это хорошо для своего Заказчика, но в конечном итоге ты всё равно плохой для него.
Это та ситуация, когда быть результативным руководителем проектов и «деливерить» недостаточно.
Причины большого потока задач:
- Объем выделенного бюджета на развитие КИС позволяет многое реализовать в ней.
- Большое количество локальных решений на основе Excel и Access на отказ от которых задано направление развития КИС.
- Пользователи и Заказчики, привыкшие к тому, что каждый запрос реализуется.
- Сотрудники ДИТ, привыкшие к тому, что всё равно что делать, что попросят то и сделают.
На рисунке морально-психологическое состояние директора ДИТ при изучении списка запросов из которых он должен выбрать те, что мы будем делать.
Начали мы с того что ввели ТЭО для запрашиваемых разработок / доработок и внедрений ИТ-решений.
ТЭО состояло из оценки трудоемкости реализации задачи и ожидаемого экономического эффекта. Трудоемкость реализации предоставлял ДИТ, оценку экономического эффекта — Заказчик. Обоснование показало какие задачи способны себя окупить и за какой период.
Проблема: У части Партнеров сотрудники, оформляющие кредитные договора, не имеют доступа в интернет (внутренняя политика банков), по этой причине существует лаг между выходом нового шаблона договора и получением его сотрудниками, это приводит к использованию устаревших шаблонов и оформлению дополнительных соглашений к заключенным кредитным договорам.
Иногда случается, что сотрудники Партнеров вносят изменения в шаблон кредитного договора, что приводит к необходимости проверять формулировки кредитного договора на соответствие эталонным, и если они не соответствует, проводить анализ внесенных изменений и необходимых действий.
Цель: Сократить время, затрачиваемое Экспертом, на проверку Кредитного договора засчет реализации проверки кредитного договора Корпоративной ИС.
Технологическое решение:
Использовать ИТ-решение компании 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 Партнеров.
Указанное решение привело к тому, что свело на «нет» огромный поток запросов с мелкими и «дурацкими» доработками, которые не приносили добавочной стоимости, но расходовали ресурсы.
Период, когда сотрудники пытались автоматизировать всё что могло быть автоматизировано, чтобы ничего не делать руками, закончился.
ТЭО привело ситуацию к тому, что теперь ресурсы ДИТ были сосредоточены на самых выгодных для компании задачах и проектах. Оно решило первую часть проблемы, теперь ресурсы использовались эффективно. Оставалась вторая — Заказчики по прежнему были не довольны тем, что ДИТ не делал то, что просят.
На рисунке изменение в лучшую сторону морально-психологического состояния директора ДИТ при выборе запросов на реализацию.
Каждому Бизнес-Подразделению устанавливались на год показатели (KPI), которых оно должно достичь. Для достижения этих показателей Бизнес-Подразделения порождали запросы в ДИТ на предоставление необходимых ИТ-решений. Ситуация с ТЭО привела к тому, что задачи зарабатывающих подразделений получали больше ресурсов, а обслуживающие (тратящие) подразделения оказались на положении «бедных» родственников.
У первых проекты были направлены на то, чтобы больше зарабатывать, а у вторых на то, чтобы сэкономить. Экономить/повышать эффективность собственной работы было менее выгодно, чем придумывать решения о том как зарабатывать больше. Обусловлено это было тем, что
Так как ДИТ принимал решение о том какие задачи реализовывать и куда направлять бюджет, это породило обвинения в адрес ДИТ, что мы игнорируем задачи сервисных бизнес-подразделений и отдаем предпочтение задачам зарабатывающих.
Решение пришло не сразу, так как с одной стороны всё было в порядке. Ресурсы попадают в самые выгодные для компании задачи и проекты. С другой стороны, выходит что неправильно ставить перед подразделениями показатели, которых они должны достичь, и не обеспечивать их необходимыми ресурсами для этого.
Приняли решение поделить бюджет между подразделениями в соответствии с накопленным объемом авторизованных задач. Для этого посчитали объем требуемых ресурсов на реализацию всех задач и определили долю задач каждого бизнес-подразделения в этом объеме. В этих долях «роздали» бюджет.
ДИТ по прежнему отвечал за бюджет, но теперь каждое бизнес-подразделение само решало на какие задачи, на достижение каких годовых показателей, направить выделенную ему сумму.
Так решили вторую часть проблемы, делали то, что просит Бизнес-Подразделение в рамках имеющихся у него для этого возможностей.
Что получили- Задачи, которые целесообразно делать с точки зрения выгоды для бизнеса компании.
- Обеспечили реализацию задач и проектов каждого подразделения без необходимости сравнивать важность задач подразделений между собой.
- Предоставили Бизнес-Подразделению возможность самостоятельно решать на реализацию каких ИТ-запросов направить бюджет для достижения годовых плановых показателей.
- Планирование расходования бюджета с Бизнес-подразделением так, чтобы его хватило на год и все самые важные инициативы были реализованы.
- Возможность выходить на Бюджетный Комитет с предложением по увеличению ИТ-бюджета компании подкрепленным перечнем задач Бизнес-Подразделений с положительным ТЭО, которые не были реализованы в прошлом году в виду недостатка бюджета.
На рисунке «Happy End».
ТЭО Бизнес-Подразделениям было не нужно, они в нем не были заинтересованы.
Во-первых — они хотели всё что просят.
Во-вторых — получаемый экономический эффект потом проверят.
За то ТЭО было понятно и нужно Руководству Компании, поэтому этот инструмент внедрялся по решению «сверху».
На то, чтобы научить Бизнес-Подразделения формировать внятное ТЭО ушел не один год.
Деление бюджета между бизнес-подразделениями повлекло проведение организационных изменений внутри ДИТ. Каждое бизнес-подразделение было закреплено за конкретным Руководителем Проектов. В последствии введена позиция Руководителя Направления. В зону её ответственности вошли управление бюджетом и портфелем проектных и не проектных ИТ-запросов бизнес-подразделения.
Что почитать по теме- Стратегии формирования портфеля заказов на предприятии, выпускающем продукцию под заказ
- Оптимизация работы веб-студии. Применение теории ограничений в производстве сайтов
- Применение Теории Ограничений Систем для постановки процесса
Поделитесь в комментариях своими «кейсами» и ссылками на известные вам истории по теме. Этим вы поможете мне собрать, а другим читателям получить обзор практики.
Если после прочтения статьи у вас возникло желание потревожить мою карму Минусом, то оставьте ниже комментарий к нему, что в статье и моей личности вас задело и не понравилось. Учту вашу позицию и мнение в будущем.
Комментарии (2)
7 ноября 2016 в 10:49
0↑
↓
А как быть, если есть большое множество мелких задач, не делать которые нельзя, но введение «Технико-Экономического Обоснования» настолько повысит их стоимость (это же тоже не бесплатный процесс), что они станут невыгодными?
Locolind
7 ноября 2016 в 11:29 (комментарий был изменён)
0↑
↓
Ответ кроется вот в этом противоречиине делать которые нельзя
, нонастолько повысит их стоимость (это же тоже не бесплатный процесс), что они станут невыгодными
Если после составления ТЭО задачу становится не выгодно делать, то ее уже можно не делать.Цель ТЭО — остановить поток таких мелких, которых делать нельзя, задач так как польза для компании от них либо минимальна либо вообще никакой, если они даже затрат на составление ТЭО не окупают. И сосредоточить имеющиеся ресурсы на тех задачах, которые будут приносить максимальную отдачу для Компании и Клиентов.
Пример.
Задача №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-а.Если этого не делать, мы чаще будем «жечь» дефицитные и дорогостоящие ресурсы разработки в пустую, чем создавать что-то реально ценное.
