Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
А как быть, если есть большое множество мелких задач, не делать которые нельзя, но введение «Технико-Экономического Обоснования» настолько повысит их стоимость (это же тоже не бесплатный процесс), что они станут невыгодными?
Ответ кроется вот в этом противоречии
Если после составления ТЭО задачу становится не выгодно делать, то ее уже можно не делать.
Цель ТЭО — остановить поток таких мелких, которых делать нельзя, задач так как польза для компании от них либо минимальна либо вообще никакой, если они даже затрат на составление ТЭО не окупают. И сосредоточить имеющиеся ресурсы на тех задачах, которые будут приносить максимальную отдачу для Компании и Клиентов.
Пример.
Задача №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-а.
Если этого не делать, мы чаще будем «жечь» дефицитные и дорогостоящие ресурсы разработки в пустую, чем создавать что-то реально ценное.
не делать которые нельзя, но
настолько повысит их стоимость (это же тоже не бесплатный процесс), что они станут невыгодными
Если после составления ТЭО задачу становится не выгодно делать, то ее уже можно не делать.
Цель ТЭО — остановить поток таких мелких, которых делать нельзя, задач так как польза для компании от них либо минимальна либо вообще никакой, если они даже затрат на составление ТЭО не окупают. И сосредоточить имеющиеся ресурсы на тех задачах, которые будут приносить максимальную отдачу для Компании и Клиентов.
Пример.
Задача №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-а.
Если этого не делать, мы чаще будем «жечь» дефицитные и дорогостоящие ресурсы разработки в пустую, чем создавать что-то реально ценное.
Лучше потратить полрубля на ТЭО и не делать задачу, чем тратить два рубля на её реализацию.
Это уже экономия для компании 1,5 рублей.
Это уже экономия для компании 1,5 рублей.
Если говорить на этом примере, то у нас считается, что тогда лучше ТЭО не проводить вовсе, а выполнить произвольно выбранную четверть задач без ТЭО. Четверть всех задач лучше, чем ни одной.
Уж не знаю, насколько это правильнее или неправильнее…
Уж не знаю, насколько это правильнее или неправильнее…
Каждый тратит свои деньги так как считает нужным. Статья о том, как деньги считать и вкладывать с отдачей.
Но от четверти выполненных задач будет хоть какая-то отдача.
А какая отдача будет от толстой пачки отрицательных ТЭО?
А какая отдача будет от толстой пачки отрицательных ТЭО?
Но от четверти выполненных задач будет хоть какая-то отдача.
Она будет скорее эмоциональная, чем экономическая.
Вам будут благодарны за то, что вы сделали, но вот сколько выгоды в рублях и есть ли она это неизвестно.
При этом будет то что можно точно замерить, это сколько времени было затрачено на их реализацию, и сколько вы должны получить в кассе предприятия.
Затраты, которые будут профинансированы из прибыли компании.
Представьте, что и Продавцы в компании будут работать также. Не оценивать привлекательность клиентов, а продавать каждому желающему по одной ручке за 1 рубль, затрачивая на это по 2-3 дня своего рабочего времени на сделку. Долго такой бизнес не протянет.
Какая отдача от от толстой пачки отрицательных ТЭО
- В компании появляется навык считать деньги / быстро делать разумное ТЭО
- Компания перестает разбрасываться деньгами и сосредотачивается на действительно выгодных и ценных задачах
- у вас появляется время на того, чтобы прочесть книгу или поучится каким-то интересным и новым технологиям, которые повысят эффективность вашей работы вместо того чтобы тратить деньги компании на то что имеет неподтвержденную ценность.
Можно не кидаться делать эти мелкие задачи сразу, как только они возникнут, а собрать в «пачку», сделать ТЭО для «пачки» и уже принимать решение на основе дроби Эффективность/Затраты.
Скорее всего, на нижнем уровне при таком подходе начинается саботаж новых продуктов и все возвращается обратно в Exсel.
Из моего опыта лучшее решение, это отправить программистов на неделю в бухгалтерию и заставить их пользоваться своими творениями. Обычно после этого у них на многие «ненужные» задачи внезапно появляется другой взгляд.
Из моего опыта лучшее решение, это отправить программистов на неделю в бухгалтерию и заставить их пользоваться своими творениями. Обычно после этого у них на многие «ненужные» задачи внезапно появляется другой взгляд.
у автора речь не идет о том, что программист делает что-то плохо, а о том, что большая часть "хотелок" пользователей экономически нецелесообразна с точки зрения прибыли компании
Я немного не о том. Тети в бухгалтерии не будут думать о целесообразности. Они просто вернутся к привычным и работающим инструметам (вплоть до калькуляторов), а фичи, добавляемые в продукт и одобреные десятком вицепризедентов, использоваться не будут. Т.е. при таком подходе мы наталкиваемся на типичную проблему, когда ДИТ делает на бумаге все очень круто, но на деле занимается совершенно бесполезной работой. Подобный собатаж на мой взгляд самый большой головняк в больших компаниях. И единственное рабочее решение которое я знаю, это иметь своего человека среди целевой аудитории или отрправлять туда программистов на искупление.
такие вещи решать надо только сверху, саботаж надо сразу брать за рога. я 9 лет наблюдаю описанные в сабже проблемы и саботаж. И это реально потерянные финансы компании.
С таким подходом можно влипнуть в типичные проблемы иерархических систем: задержки управлющих сигналов, показуха, неэффективность. Ну не может начальник ДИТ и другой начальник решить насколько нужна какая-нибудь формочка или отчет. Они слишком высоко стоят в иерархии. Когда они пытаются на это отвлекаться, то либо не успевают, либо увязают в бюрократии.
Для эффективной разработки очень нужны горизонтальные связи с заказщиком (внутренним или внешним).
Для эффективной разработки очень нужны горизонтальные связи с заказщиком (внутренним или внешним).
С таким подходом можно влипнуть в типичные проблемы иерархических систем: задержки управлющих сигналов, показуха, неэффективность.
Вы правы, мы столкнулись с торможением и пошли по пути который вы предложили.
Выглядел он в двух словах так:
- Задачи стоимостью до 500 тысяч рублей согласовывает Начальник отдела.
- От 500 тысяч до 1 млн. рублей заместитель директора департамента, заказывающего бизнес-подразделения.
- От 1 млн. рублей до 3 млн.рублей директор департамента.
- Свыше 3 млн. рублей контроль на уровне заместителей генерального директора, курирующих бизнес-блок.
Заместителю генерального директора некогда и неинтересно согласовывать доработку формочки за 100 000 рублей.
Если есть ТЭО и оно говорит, что её выгодно дорабатывать, ему этого достаточно.
То что выгода будет достигнута, проверит Внутренний Аудит.
Если не будет достигнута, Заказчика наказать не накажут, но проверят окупится ли хотя бы и возьмут на заметку.
А что делать с задачами стоящими, скажем 1000 рублей каждая, но которых, скажем 1000 в бэклоге? Обычно такие мелкие задачи составляют основной процент работы каждого программиста.
Группировать по заказчикам и/или объектам, которые требуется доработать.
А далее как в приведенном комментарии
https://habrahabr.ru/post/314448/#comment_9897288
А далее как в приведенном комментарии
https://habrahabr.ru/post/314448/#comment_9897288
Можно не кидаться делать эти мелкие задачи сразу, как только они возникнут, а собрать в «пачку», сделать ТЭО для «пачки» и уже принимать решение на основе дроби Эффективность/Затраты.
И опять упераемся в задержки. Между релизом продукта, собиранием пачки, написанием ТЭО на пачку и собственно её отработкой пройдет существенный срок, за который можно и экспертизу растерять и дизлайк получить от бизнеса.
Каждый тратит свои деньги так как считает нужным. Статья о том, как деньги считать и вкладывать с отдачей.
Если денег много, можно всю 1000 задач по 1000 рублей сделать, за этим прилетит ещё 1000 по 1000, из которых 500 будет переделать то, что сделали раньше, либо чтобы вернуть как было либо потому что надо по другому.
Но в целом ваш вариант вполне рабочий, посадили программиста со знанием предметной области в «песочницу» и там он с Заказчиком что-то лепит.
Если нужны какие-то сквозные изменения затрагивающие работу нескольких подразделений, ваш вариант потребует усложнений и изменения «архитектуры» системы, при этом в последующем ваш программист не может менять тот «кирпич», который у него отмечен, что им пользуется соседнее подразделение.
Для этого придется с ним договорится об изменениях в нём.
дизлайк получить от бизнеса
Когда денег в компании станет меньше, а привычка получать от ИТ всё что хочется останется, у вас начнет бэк-лог увеличиваться, а вот новых ресурсов вам не дадут, так как денег нет в компании.
Вы и придёте к описанной ситуации, что вы делаете что-то полезное для бизнеса, а вам говорят что этого мало и медленном, получите дизлайки от бизнеса.
Что что-то нужно менять.
знаете, такой подход все равно будет в сотни раз выгоднее компании. у нас куча внутреннего ПО, которое обслуживают десять программистов, срок по перспективным задачам от 3 месяцев и в года. программы на фокспро, тягающие файловые БД, акцесс, дельфи и прочий зоопарк.
«Тети в бухгалтерии» тоже привыкают думать перед тем как что-то запросить, если это надо как-то аргументировать, кроме «мне надо и ОЧЕНЬ срочно».
По факту в большинстве случаев оказывается, что:
— надо автомизировать подготовку отчета, который нужен один раз в год,
— если все таки ДИТ это сделал, и прпросил проверить (протестировать) — сразу получаем ответ: у меня нет времени. и к этой задаче больше никогда не возвращаются.
Если есть задача, которая реально нужна — можно нормально агруменировать, а не «вернутся к привычным и работающим инструметам (вплоть до калькуляторов)».
По факту в большинстве случаев оказывается, что:
— надо автомизировать подготовку отчета, который нужен один раз в год,
— если все таки ДИТ это сделал, и прпросил проверить (протестировать) — сразу получаем ответ: у меня нет времени. и к этой задаче больше никогда не возвращаются.
Если есть задача, которая реально нужна — можно нормально агруменировать, а не «вернутся к привычным и работающим инструметам (вплоть до калькуляторов)».
Да черт возьми, иногда надо автоматизировать отчет, который нужен раз в год. Переодические отчеты, в то числе годовые могут отнимать чудовищное количество времени у бухгалтера и их сведение это одна из важнейших операций.
В этом и беда: IT совсем не понимают как работает бухгалтерия, которую они пытаются автоматизировать.
В этом и беда: IT совсем не понимают как работает бухгалтерия, которую они пытаются автоматизировать.
В этом и беда: IT совсем не понимают как работает бухгалтерия, которую они пытаются автоматизировать
Если развивать мысль, то ИТ нужно будет отправить и в продажи и в маркетинг и в логистику… во все бизнес-подразделения понимать как они работают и какие операции какой сложностью и трудоемкостью обладают.
Мне хочется уберечь Разработчиков от этих «душевных травм и драм» и отправлять в бизнес-подразделения Бизнес-аналитиков, чтобы они делили боль Заказчиков из бизнес-подразделений.
Переодические отчеты, в то числе годовые могут отнимать чудовищное количество времени у бухгалтера и их сведение это одна из важнейших операций.
Не поспоришь, всё что отнимает чудовищное количество времени у сотрудников нужно изучать и думать можем ли мы эти затраты уменьшить.
И делать это не только из чувства сострадания бухгалтеру, но и потому что это выгодно.
Ну если коротко, то да, я считаю что программист должен разбираться в той сфере в которой пытается действовать, иначе его эффективность сильно падает.
Всегда дешевле иметь одного спеца бухгалтер+1C, который подчиняется начальнику бухгалтерии, чем по отдельности бизнесаналитик, начальник ДИТ, чистый программист. Задержки в этой цепочке слишком велики, а в наше время решают не технологии а скорость их внедрения. Да и экономия от увольнения двух лишних в цепочке людей будет существенной, даже с учетом более высокой стоимости квалифицированного человека и неизбежного дубляжа позиций в разных отделах.
Всегда дешевле иметь одного спеца бухгалтер+1C, который подчиняется начальнику бухгалтерии, чем по отдельности бизнесаналитик, начальник ДИТ, чистый программист. Задержки в этой цепочке слишком велики, а в наше время решают не технологии а скорость их внедрения. Да и экономия от увольнения двух лишних в цепочке людей будет существенной, даже с учетом более высокой стоимости квалифицированного человека и неизбежного дубляжа позиций в разных отделах.
Часто проблема автоматизации отчета, который нужен раз в год в том, что на следующий год он уже другой. Особенно если он спущен сверху.
который нужен раз в год в том, что на следующий год он уже другой
Иногда реально выгоднее, чтобы какой-то отчёт формировали сами бухгалтера в Excel, нежели потратить ресурсы ИТ на вникание в детали задачи, доработку, тестирование и релиз. Если это будет использоваться всего раз, то нет и смысла это автоматизировать. В противном случае это двойная работа.
Всегда дешевле иметь одного спеца бухгалтер+1C, который подчиняется начальнику бухгалтерии, чем по отдельности бизнесаналитик, начальник ДИТ, чистый программист.
Во-первых, вы переходите от общего к частному. Компания в которой один программист способен справиться со всем потоком задач всей организации действительно выгодно иметь такую структуру. Но даже в статье рассматривался пример, когда программистов должно быть больше.
Во-вторых, очень тяжело и дорого быть спецом сразу в двух направлениях. Зачастую у программист+бухгалтера страдают оба направления. Программист должен знать предметную область настолько, насколько ему необходимо для решения задачи. Поэтому даже в статье приведён пример, когда сотрудники ИТ закреплены за определёнными направлениями.
Сам сталкивался с ситуацией, когда работал в сфере ЖКХ. Хотя были предоставлены все необходимые инструменты реально влияющие на бизнес, бухгалтера по прежнему в упор не хотели их использовать. Тогда я убедился, что проблемы были на 90% из-за лени бухгалтерии (ещё 10% это отсутствие финансирования и большие задержки зп).
Собственно поэтому та компания и развалилась. Они просто не смогли конкурировать.
Да черт возьми, иногда надо автоматизировать отчет, который нужен раз в год. Переодические отчеты, в то числе годовые могут отнимать чудовищное количество времени у бухгалтера и их сведение это одна из важнейших операций
Так никто не спорит, что это возможно надо сделать. Просто для того, чтобы это было сделано, бухгалтеру надо описать как это делается чейчас, сколько времени на это уходит, почему это важно и т.д.
И уже решение будет приниматься на основании указанных данных, а не на эмоциях и громкости голоса.
Скорее всего, на нижнем уровне при таком подходе начинается саботаж новых продуктов и все возвращается обратно в Exсel.
Личное наблюдение.
Там где начинается саботаж новых продуктов, эти компании начинают проигрывать конкурентную борьбу. Вопрос в том на сколько хватит прочности у организации.
Там где в компаниях экспериментируют и пробуют что-то новое, случаются и инсайты и кратный рост эффективности, работать и интересно и платят хорошо, так как есть из чего платить.
Из моего опыта лучшее решение, это отправить программистов на неделю в бухгалтерию и заставить их пользоваться своими творениями. Обычно после этого у них на многие «ненужные» задачи внезапно появляется другой взгляд.
Похоже на то, что программисты получают новую квалификацию «Бизнес-аналитиков» и для них задачи перестают быть «обезличенными», они понимают для кого и что они делают, удобно ли этим пользоваться и есть ли эффект.
Ваш посыл мне в целом понятен.
Добавил бы что «рыба гниёт с головы», но часто не в наших силах заменить Руководителя в подразделении.
В моем случае это сводилось к тому, что я начинал выбирать «вменяемых» внутренних Заказчиков, которым была нужна возможность. Работа с ними, со временем, начинает отрезвлять окружающую обстановку и подтягиваются другие адекватные заинтересованные лица.
Прочитал по диагонали, в целом годный подход.
Тут нужен очень и очень матерый продукт оунер, у которого хватит сил и опыта послать тех, чьи задачи решают узкие кейсы за большие деньги.
Следовать подходу, кто платит, тот и заказывает музыку, но опять таки надо учитывать цели и перспективы развития системы, т.е. прямое распределение реализованных задач по бюджету может быть не до конца верным.
Тут нужен очень и очень матерый продукт оунер, у которого хватит сил и опыта послать тех, чьи задачи решают узкие кейсы за большие деньги.
Следовать подходу, кто платит, тот и заказывает музыку, но опять таки надо учитывать цели и перспективы развития системы, т.е. прямое распределение реализованных задач по бюджету может быть не до конца верным.
Спасибо за статью, даже баззовые вещи надо постоянно повторять, что бы никогда про них не забывать :).
На практике в итоге все упирается в руководство — если руководитель компании понимает, что это надо делать, то все будет хорошо. Если нет — помочь нечем, только посочувствовать руководителю ИТ, рано или поздно его съедят и пользователи уйдут в режим «мы ничего не сделали т.к. ИТ во всем виновато». И помочь ИТ руководителю в принципе нечем, увы. Чем заканчивается потом тоже могу рассказать, но это уже не так интересно.
Кстати, для небольших контор или в случае большого потока мелких задач делаем комитет (обязательно должен входить руководитель стоящий выше директоров департаментов и принимающий решение в случае споров) и планируем работы на комитете с горизонтом 1-2 недели.
ТЭО делается только на проекты в числе прочей документации.
P.S. Кстати, вы извините, но пример ТЭО некорректный — классический пример манипулирования цифрами. Хуже только «повышение прозрачности» и прочая демагогия. Мне в свое время повезло с руководителем возглавляющим комитет, на эти часы экономии он брал блокнот и говорил, «отлично, после реализации сколько человек сокращаем в вашем отделе?». А на чудо-проекты от коммерсов спрашивал «на сколько миллионов увеличиваем план продаж?». Т.е. ТЭО должен выражаться в конкретных цифрах прибыли или экономии, остальным манипулировать может даже ребенок.
На практике в итоге все упирается в руководство — если руководитель компании понимает, что это надо делать, то все будет хорошо. Если нет — помочь нечем, только посочувствовать руководителю ИТ, рано или поздно его съедят и пользователи уйдут в режим «мы ничего не сделали т.к. ИТ во всем виновато». И помочь ИТ руководителю в принципе нечем, увы. Чем заканчивается потом тоже могу рассказать, но это уже не так интересно.
Кстати, для небольших контор или в случае большого потока мелких задач делаем комитет (обязательно должен входить руководитель стоящий выше директоров департаментов и принимающий решение в случае споров) и планируем работы на комитете с горизонтом 1-2 недели.
ТЭО делается только на проекты в числе прочей документации.
P.S. Кстати, вы извините, но пример ТЭО некорректный — классический пример манипулирования цифрами. Хуже только «повышение прозрачности» и прочая демагогия. Мне в свое время повезло с руководителем возглавляющим комитет, на эти часы экономии он брал блокнот и говорил, «отлично, после реализации сколько человек сокращаем в вашем отделе?». А на чудо-проекты от коммерсов спрашивал «на сколько миллионов увеличиваем план продаж?». Т.е. ТЭО должен выражаться в конкретных цифрах прибыли или экономии, остальным манипулировать может даже ребенок.
Кстати, вы извините, но пример ТЭО некорректный — классический пример манипулирования цифрами. Хуже только «повышение прозрачности» и прочая демагогия.
Вы меня ничуть не задели и у нас не просто спрашивали сколько человек сокращаем, а пытались сокращать.
И если сотрудников не сокращали, то спрашивали куда ушла экономия.
В результате это стало сильным мотиватором для бизнеса начать использовать JIRA в своей работе, чтобы ответ на этот вопрос был прозрачен / оцифрован.
Если в компании никто не проверяет достигнут ли был результат, то вы правы люди только научаться манипулировать цифрами и уметь с их помощью обосновывать свои задачи.
Это уже полшага вперёд.
Здесь есть два варианта, что будет дальше. Мы использовали оба.
Первый — Руководство перестало давать ресурсы подразделениям на прямую. То есть для достижения увеличившихся показателей вы не можете получить ещё людей, ищите возможность повысить внутреннюю эффективность.
Например, нужно сделать уже не 10 продаж, а 20. Простой вариант, нанять ещё продавцов, а сложный это работать с воронкой продаж, конверсией и что-то оптимизировать в своей текущей работе, чтобы это время на работу с воронкой продаж и конверсией появилось.
Второй — у нас Внутренний Аудит получил новое поле для своей работы. Замерять «до» и «после».
Где-то справлялись хорошо и без него, где-то он учил руководителей считать и замерять.
Все бы хорошо, но как быть с тем фактом, что расчет эффективности и реально полученная в итоге эффективность это вещи очень плохо связанные.
Ну вот возьмем ситуацию. Приходит задача нужно срочно прикрутить супер пупер фичу к продукту, после чего его продажи обещают взлетят на 10%. Расчетный экономический эффект запредельный. Задача вырывается в топы и отжирает ресурсы. В итоге никакого реального эффекта нет, колебания продаж находятся в пределах статистической погрешности.
В итоге речь идет о состязании фейковых эффектов за ресурсы ИТ. Все все равно остаются недовольными.
Дефицит он и есть дефицит какие бы правила его распределения не придумывались все равно они не будут удовлетворять учестников процесса. Будут находится ушлые — те кто по блату или обманом будут получать ресурсы и терпилы — те кто пытается играть по честному.
Решение кроется в одном. Нужно устранять проблему «дефицит ресурсов против перепроизводства задач».
Ну вот возьмем ситуацию. Приходит задача нужно срочно прикрутить супер пупер фичу к продукту, после чего его продажи обещают взлетят на 10%. Расчетный экономический эффект запредельный. Задача вырывается в топы и отжирает ресурсы. В итоге никакого реального эффекта нет, колебания продаж находятся в пределах статистической погрешности.
В итоге речь идет о состязании фейковых эффектов за ресурсы ИТ. Все все равно остаются недовольными.
Дефицит он и есть дефицит какие бы правила его распределения не придумывались все равно они не будут удовлетворять учестников процесса. Будут находится ушлые — те кто по блату или обманом будут получать ресурсы и терпилы — те кто пытается играть по честному.
Решение кроется в одном. Нужно устранять проблему «дефицит ресурсов против перепроизводства задач».
Ну вот возьмем ситуацию. Приходит задача нужно срочно прикрутить супер пупер фичу к продукту, после чего его продажи обещают взлетят на 10%. Расчетный экономический эффект запредельный. Задача вырывается в топы и отжирает ресурсы. В итоге никакого реального эффекта нет, колебания продаж находятся в пределах статистической погрешности.
Тогда вопросы будут к тем, кто рассчитывал и заказывал задачу, а не к ИТ. Если эффекта нет, то либо ТЭО было неправильно рассчитано, либо появились обстоятельства, на которые решение данной задачи никак не могло повлиять (общее падение спроса/продаж, деградация «продажников» и т.п.). Бороться средствами ИТ с такими проблемами, всё равно что пытаться остановить торнадо usb-вентилятором: глупо, но научит отделы при рассчёте пытаться оценить и будущую ситуацию.
Будут находится ушлые — те кто по блату или обманом будут получать ресурсы и терпилы — те кто пытается играть по честному.
Такой подход так или иначе вредит организации и с ним нужно бороться даже когда в компании деньги самосвалом выгребают. Шаги описанные в статье лишь повод организационно и культурно обосновать «посыл».
Большое спасибо автору за интересную статью. Изложено без лишних подробностей, просто и понятно, без уклонения в лирику. Тема близка и понятна лично мне, считаю что автор прав.
Хочется отметить благородные но неэффективные порывы некоторых комментаторов:
1. Стараться выполнить все запросы от бизнеса — крайне неэффективная мера, так как в компании, численность которой превышает хотя бы 1000 человек, в России запросы на разработку инструментов автоматизации очень часто используются не только и не столько как реальный способ улучшить свою деятельность, сколько для перекладывания ответственности за свои недоработки на плечи других служб, в частности на службу ИТ. Отсюда и саботаж и намеренное игнорирование инструментария, чуть ли не под лозунгом «я бухгалтер/кадровик/инженер… с 20/30/100 летним стажем, я не обязан(а) разбираться в ваших компьютерах, вы должны это делать за меня, а я буду как умею» и постоянный футбол и многое другое. Такие проблемы решаются не силами ИТ а организационно, на уровне руководства организации.
2. Анализировать запросы пользователей силами ИТ-специалистов «сидящих» на различных уровнях иерархии, пытаться силами ИТ оценивать «реальный» выхлоп каждого запроса, или (страшно сказать) посадить ИТ-специалистов в бухгалтерию и другие службы, чтобы видели реальную ситуацию «на фронте» — можно любую идею довести до абсурда, посадить взамен бухгалтеров и других сотрудников «с фронта» в ИТ, чтоб тоже прочувствовали, каково это исполнять все все их копеечные запросы, прерываясь параллельно на десятки звонков их же коллег с вопросами «ну тебе же это 5 минут» и т.д.
Всё таки, работа в крупной компании, требует жёсткого подхода к управлению задачами и планированию ресурсов.
Хочется отметить благородные но неэффективные порывы некоторых комментаторов:
1. Стараться выполнить все запросы от бизнеса — крайне неэффективная мера, так как в компании, численность которой превышает хотя бы 1000 человек, в России запросы на разработку инструментов автоматизации очень часто используются не только и не столько как реальный способ улучшить свою деятельность, сколько для перекладывания ответственности за свои недоработки на плечи других служб, в частности на службу ИТ. Отсюда и саботаж и намеренное игнорирование инструментария, чуть ли не под лозунгом «я бухгалтер/кадровик/инженер… с 20/30/100 летним стажем, я не обязан(а) разбираться в ваших компьютерах, вы должны это делать за меня, а я буду как умею» и постоянный футбол и многое другое. Такие проблемы решаются не силами ИТ а организационно, на уровне руководства организации.
2. Анализировать запросы пользователей силами ИТ-специалистов «сидящих» на различных уровнях иерархии, пытаться силами ИТ оценивать «реальный» выхлоп каждого запроса, или (страшно сказать) посадить ИТ-специалистов в бухгалтерию и другие службы, чтобы видели реальную ситуацию «на фронте» — можно любую идею довести до абсурда, посадить взамен бухгалтеров и других сотрудников «с фронта» в ИТ, чтоб тоже прочувствовали, каково это исполнять все все их копеечные запросы, прерываясь параллельно на десятки звонков их же коллег с вопросами «ну тебе же это 5 минут» и т.д.
Всё таки, работа в крупной компании, требует жёсткого подхода к управлению задачами и планированию ресурсов.
Отличное ноухау.
Кстати предлагаю шаг вперед — брать задачи не только от внутренних подразделений, но и от внешних!!!
Кстати предлагаю шаг вперед — брать задачи не только от внутренних подразделений, но и от внешних!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление задачами на разработку. История из жизни