• Будни Scrum-Мастера: трансформация команды и себя
    0
    Вопрос ведь не в «как починить то, что не работает», а «зачем чинить то, что не сломано».
    Поправьте меня если я не верно вас понял. Думаю здесь вы подразумеваете, что в команде есть процедуры, которые себя зарекомендовали и работают. Когда команда начинает переходить на работу в Scrum-фреймворке, его элементы начинают входить в конфликт с этими процедурами. Если оставить всё как есть, то при очередном аудите, как у команды дела с адаптацией фреймворка, можно нарваться на заключение, что команда делает не «православный» Scrum.

    Если это то, что вы имели ввиду, то понимаю, самому порой жалко расставаться с этим, особенно когда сам принимал участие в становлении этой практики. Здесь у меня серебряной пули нет, что делать в этой ситуации. Иногда приходится «дисраптить» (разбирать на запчасти), иногда можно оставить если пользы больше чем вреда.
    Конечное решение всегда за командой, а дальше мы уже по практическим результатом поймём что с этим делать дальше.
  • Будни Scrum-Мастера: трансформация команды и себя
    0
    Получается, что ваша «Инъекция», это другое название ретроспективы из скрама? В чем отличие? Почему не хватает обычной ретроспективы?
    Всё верно. Ретроспектива — это один из базовых инструментов в копилке Скрам-Мастера, через который проходят «инъекции». Её самому на 100% можно считать примером «инъекции», которая регулярно должна происходить в команде.

    Отличие в том, что это не единственный инструмент в копилке СМ-а.
    Встречи 1-1, Организация и проведение для команды бизнес-симуляций (игр), референс-визиты, организация школ по определённым практикам (автоматическое тестирование и деплой)… — всё, что позволит команде увидеть себя со стороны и «что, а так можно было?» (к чему действительно стоит стремится / как выглядит Скрам или отдельные инструменты, когда они действительно работают как и должны).

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

    Вообще, моя основная претензия к Скраму (возможно, я не умею его готовить), это «жесткость» методологии. При том, что это вроде как Agile. Ситуация как с CrossFit'ом, который не просто «прикольная методика интервальных тренировок», а «сертифицируемая торговая марка и нужно заплатить за франшизу». Шаг вправо или влево — расстрел на месте.
    Так и тут — либо делаешь как Сазерленд написал, либо ты «предатель дела Скрама» (тут смотрим осуждающе на Скрамбат, Скрамбан и т.д.). Из-за этого ассоциации с карго-культом.
    Вопрос ведь не в «как починить то, что не работает», а «зачем чинить то, что не сломано».
    Моя точка зрения на этот счёт звучит как СюХаРи. (Сю — «соблюдать», Ха — «прорываться» и Ри — «править код»)

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

    В тот момент, когда нам во фреймворке становится тесно, мы эмпирически заменяем какие-то из базовых событий на новые или делаем их иначе (Ха).

    Например, мы научились автоматически собирать билд по коммиту, делать автотесты и деплоить по нажатию кнопки. То есть нам, чтобы доставить фичу на продуктив больше не нужно ждать конца спринта. Как только мы её закончили мы тут же можем показать её Владельцу Продукта, а он принять решение ставить ли её в этом виде на продуктив.

    Здесь инспекция результатов происходит по запросу. У Обзора спринта начинает смещаться фокус от инспекции результатов к каким-то другим актуальным для команды вещам.

    Примером же «Ри» — являются LeSS, Nexus… и больше всего новые редакции самого Scrum-фреймворка. Он же не всегда выглядел так как выглядит сейчас. Было бы забавным видеть, если бы «свидетели-последователи» разделились по историческим версиям фреймворка и воевали между собой за тот, который из них более правильный.
  • Будни Scrum-Мастера: трансформация команды и себя
    0
    Будто конспект бизнес-тренинга прочитал.

    Это плохо или хорошо?

    Что в статье есть хорошего?
    Что можно улучшить? (она не отлита в камне, я могу внести изменения)
    Чего не хватает?
  • Будни Scrum-Мастера: трансформация команды и себя
    0
    Странная получается ситуация. Вроде как Скрам это про «самоорганизацию» и «самоулучшение». А на практике, команде сначала принудительно Скрам внедрили, а потом сверху еще «надсмотрщика» поставили, чтобы он им не давал «заповеди» нарушать.

    И такое тоже бывает, но это плохой заход в сторону Скрама.

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

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

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

    «Настоящий» Скрам-мастер предпочтёт не тратить своё время впустую, а найдёт другую возможность где он будет полезен, вместо того чтобы что-то «насаждать» и получать за это зарплату.

    Понятно, что все мероприятия «по скраму», это именно что новая привычка, новый навык и нужно время для закрепления, но если команда отказывается от чего-то, возможно дело не в том, что им нужно новую инъекцию делать

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

    а в том, что они пользы не видят или ее нет

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

    Как починить то, что не работает, от чего нет пользы?
    Скрам-мастер может также пойти к другому Скрам-мастеру и с ним обсудить что не получается, позвать его в гости и попросить понаблюдать со стороны, дать обратную связь, если наш Скрам-Мастер сам не может понять в чём проблема.
  • Как я учусь практикам и ценностям Agile
    0
    questor

    image

    Описание карточек:
    2 набора карточек (по 100 шт. карточек в каждом, на группу участников примерно 10 человек). Как пользоваться GPA-карточками?

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

    GPA-карточки компетенции и обратной связи можно использовать в работе с отдельными лицами и/или коллективами (командами): 1. Различные компетенции, организованные в определенную структуру, воспринимаются всеми членами команды 2. Каждый из участников получает ответ на то, как он воспринимается в этой группе 3. Каждый получает возможность анализировать свои компетенции и проводить сравнительный анализ относительно других членов команды

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

    Ссылку на колоду карточек дать не могу так как по правилам Хабра это считается рекламой/пиаром продукта/товара (ссылка ведёт на их страницу в интернет магазине).

    Поэтому предлагаю вам погуглить вот этот текст «Карточки GPA компетенций и обратной связи»
  • Увольнять, нанимать, повышать — культура вашей компании
    0
    Вы молодец.
    Заметил, что ошибку поправили и «Честность» заняла своё место.
  • Увольнять, нанимать, повышать — культура вашей компании
    0


    А благодарность была высказана 22 июля в 17:14.

    Рад, что вы с нами на хабре, мы с удовольствием вкладываем своё время и силы в развитие коллег по цеху.
  • Увольнять, нанимать, повышать — культура вашей компании
    +3
    Sherbinin интересный пример проявления «милой» реакции с неэффективным результатом: в статье «целостность» осталось на месте, хотя должно было быть заменено на «честность».

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

    Вывод: Социальные навыки присутствуют)

    integrity: варианты перевода
    имя существительное
    целостность — integrity, continuity, integrality
    неприкосновенность — immunity, inviolability, integrity, sanctity, untouchability
    честность — honesty, integrity, fairness, probity, honor, uprightness
  • Стоимость качества в разработке программного обеспечения
    +2
    Это и имел ввиду под «Мы же профессионалы».

    Заказчику нужно быстро и дешево, а если будут проблемы то в этом виноваты конечно же мы, команда разработки, что плохо сделали свою работу. А если мы делаем свою работу плохо, то логично же что нам недостает квалификации. Настоящие же профессионалы работают хорошо, быстро и дешево. — скажет Менеджер / Заказчик.

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

    «Чтобы мы были теми переменами которых ищем».
  • Стоимость качества в разработке программного обеспечения
    +2
    но в статье всё настолько идеализировано и упрощено

    Это даётся не просто, через постоянные тренировки.

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

    И начинать стоит с простого и прагматичного. Затем посмотреть на историях гуру менеджмента качества как эволюционировали идеи про качество и уже отсюда двигаться в ITIL, COBIT, CMMI, SWEBOK и серию ISO.

    Внедрять информационные системы типа Atlassian JIRA, чтобы построить учет ошибок и дефектов в разрезе версий выпущенного ПО, планировать их устранения по будущим версиям, автоматически собирать данные о затратах на их устранение, типизировать, по правилу «20 на 80» устранять самые тяжелые.

    Осваивать технологии Test Driven Development, Behavior Driven Development, Continuos Integration, Интерактивного прототипирования без разработки.

    Наши реалии таковы, что прихожу я в большой банк познакомится с ИТ-директором и он просит меня помочь им продать CI бизнесу (бизнес-подразделениям) при этом говорит что всё что мы можем сказать — сколько это будет стоить (сколько и какого железа и софта нужно будет купить, сколько человек ещё нанять), а вот какой эффект банк и его бизнес от этого получит нет. Также есть серьезная проблема с наличием актуальной документации на текущие эксплуатируемые системы.

    В итоге все выглядят как папуасы на острове, увешанные бусами и всякими другими модными штуками, где микроскопом колют кокосы.
  • Стоимость качества в разработке программного обеспечения
    +1
    Оно подразумевается) Мы же профессионалы.

  • Стоимость качества в разработке программного обеспечения
    0
    То есть, вы утверждаете, что баг, пропущенный при разработке по водопаду, после релиза, гораздо дешевле бага, который нашли во время тестирования?


    Не утверждаю, а можете на материале статьи пояснить как у вас сформировался этот вывод?! Свою логику.

    «Водопад» предполагает и включает в себя этап «тестирования». Поэтому когда вы сравниваете ошибку сделанную в разработке ПО по «водопадной» модели, с «нашли во время тестирования» не понимаю о чем вы.

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

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

    Вот статья которая это иллюстрирует — Пьеса «Технический долг».
    Как это лечить описано в статье «будущее гибкой разработки».

    Я выступаю за использование фреймворков гибкой разработки, которые требует от работающих в них более высокой «инженерной культуры», повышением которой мы, пишущие и читающие на Хабре, и занимаемся.
  • Стоимость качества в разработке программного обеспечения
    +1
    Готово. Можете воспользоваться.
  • Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов
    0
    dmitrybelsky,
    Сперва вы были против того, что я назвал проект большим, а по вашим меркам он таковым не является. (Общепринятого стандарта-мерки нет или приведите ссылку на него, чтобы доказать обратное)

    Теперь вы против того, что мы проэкспериментировали с новым фреймворком управления проектами на «мелком ненужном проекте», то есть мы должны были взять что-то покрупнее, чтобы словить указанные вами риски и увеличенные соразмерные проекту затраты на освоение на крупном проекте, верно?
  • Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов
    0
    dmitrybelsky,
    Моему работодателю эта статья не стоила ни копейки, а проект имел защищенное Технико-Экономическое Обоснование и генерировал прибыль компании более 5 лет.

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

    На нормального проджекта ничего нельзя повесить. Где сели, там с него и слезите, потому что это нормальный проджект. Нормальный РМ работает на своё портфолио и репутацию. На не нормального можно повесить хоть 100 таких проектов. В этот раз вы уже не в ладу с собственной математикой про 0.2-0.3 FTE.

    Судя по вашей манере общения, вы менеджер среднего звена (B-level) которому повезло перескочить уровень работы «нормальным PM-ом», потому позволяете себе много вольностей и видимо не только на сайте, но и в работе. «Чего нет в игре, того нет и в жизни.» (с — Сергей Кириенко)

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

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

    Критерии приемки:
    1. это соответствие того, что выдает продукт, тому что записано в качестве выхода для системного сценария использования.
    2. это отработка всех системных сценариев в симфонии (целостность выполнения бизнес-сценария).


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

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

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

    Повторюсь, идея такая — делать документацию там где уже есть проблемы или где это экономически оправдано. Иначе вместо работы мы будем заниматься тем, что раскладывать солому во всех местах где можем подскользнуться.
  • Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов
    0
    ganqqwerty, вы задали хороший вопрос.

    Краткий ответ таков: Не делайте документацию, которая вам не нужна.

    Длинный ответ:
    У RUP и у Стандарта управления проектами (PMI, PMBoK) предусмотрено множество документов, которые призваны помочь сделать проект/продукт, но это не значит что в первом случае надо обложится всевозможными UML-диаграммами, а во втором — планами на каждый возможный чих.

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

    Поэтому предлагаю делить документацию на базовую (core) и факультативную (optional). Первая однозначно нужна в любом случае и должна быть всегда актуальной. Вторая делается под конкретную ситуацию и необязательна должна быть актуальной.

    Вот моё представление о базовой документации:
    1. В основе всего лежит один документ, который описывает текущую реализацию бизнес-процесса в контексте использования информационной системы. В карточке описания бизнес-процесса указывается, на каких функциональных модулях системы он построен.
    2. Как только бизнес хочет начать работать по другому, мы перепроектируем бизнес-процесс и указываем какие его участки на что меняем. К этому привязываются изменения в функциональных модулях.
    3. Если другой бизнес-процесс пытается использовать для себя функциональный модуль, то Реестр ТЗ подсказывает какие бизнес-процессы уже на нём сидят.
    4. В итоге для бизнеса всё сводится к трём документам: Документ версии 1.0, Вносимые изменения, Документ версии 1.1. И такая же картина с технической стороны для функциональных модулей (подсистем).


    Весь список «бумажек» нужный для разработки и доработки:
    1. Реестр ТЗ.
    2. ТЗ бизнес-часть (содержит описание бизнес-сценария и его системных сценариев использования).
    3. Дополнение к ТЗ бизнес-часть (содержит указание что на что меняем в бизнес-сценарии и системных сценариях), как правило, после выполнения работ и подготовки обновленной версии ТЗ «выкидывается».
    4. ТЗ техническая часть (содержит раскладку системных сценариев на сущности системы).
    5. Дополнение к ТЗ техническая часть.


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

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

    Пример того, как это работает Каким должно быть ТЗ на Корпоративную ИС?

    Честно скажу, что считаю что вам лучше знакомы методы как уменьшить количество производимых документов. Посмотрел ваши статьи про то что вы разрабатываете базы знаний, а производимая документация и есть база знаний.
  • Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов
    0
    dmitrybelsky у вас корректная математика.
    Специально для вас написал статью Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)

    Вы упускаете из виду окружающий контекст проекта: был ли у меня в работе только этот проект или их было много, может ли быть вся команда разработки отдана Заказчику на данный проект и все прочие работы по развитию системы остановлены, позволяет ли архитектура системы распараллелить работы по разным проектам…

    И делаете выводы:
    Мораль — автора надо увольнять за профнепригодность и трату времени на всякую хрень вместо работы

  • Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов
    0
    Бизнес всегда интересуют сроки, когда они получат новую нужную им «фичу».
    Это он требует указания срока, какой бы вы технологический подход/метод не использовали бы для разработки.

    В Kanban как и в Scrum есть Product Backlog. В обоих случаях они должны быть приоритезированны, чтобы можно было понять какие задач делать в первую очередь и в какой последовательности.

    Сроки для задач в в Scrum высчитываются из длительности спринта, его емкости (часов в спринте) и трудоемкости задачи (часов на её выполнение). Часы здесь условно, хоть в попугаях может быть единица измерения.
    image
    Гибкое планирование выпуска релизов 101 (на основе Excel)

    Сроки в Kanbane определяются на основе показателя срока нахождения задачи на доске (время цикла) и ограничения на количество задач в работе. Если одновременно делать можно две задачи. То приведенному выше списку задач также можно построить прогноз.
    Канбан в IT (Kanban Development).

    Проблема и Waterfall, и RUP, и Scrum в том, что внутри списка релиза всегда находятся уже выполненные задачи, которые ждут даты назначенной для выхода релиза.
    В случае с Waterfall — полгода, c RUP — квартал, с Scrum — от недели до месяца. В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.

  • Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов
    0
    Благодарю и вас, что нашли время почитать и вспомнить.
    Статья вышла длиннее обычного.
  • Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов
    0
    В PM Book ничего не расписано, никаких frameworks там нету.

    В пятой версии начиная со страницы 417 «Приложение А1 Стандарт управления проектом»

    А фазы, что вы указали для RUP присутствуют в любом проекте.

    А вы не путаете фазы проекта с типами работ?

    В классическом представления каждая фаза проекта соответствует одному типу работ. В парадигме RUP в каждой фазе проекта могут быть выполнены все типы работ: Сбор требований, Анализ, Проектирование, Разработка, Тестирование и Внедрение, — и не по одному разу, если фаза содержит более одной итерации.

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

    Вам повезло, что заказчик уже побегал по граблям и согласился на вменяемый бизнес-анализ

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

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

    Благодарю что оценили наше грамотное планирование.
    Вдохновлялись книгой Ivar Jacobson «The Unified Software Development Process»
  • Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов
    0
    Согласен с вами.

    Каскадная модель — это парадигма.
    За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
    К сожалению для него нет другого названия, которое было бы общепринятым, кроме как Waterfall.
    Поэтому в статье используется оно.

    RUP — это методология, которая относится к Инкрементальным и Итеративным моделям (парадигмам).
  • Анализ и сравнение своего ИТ-продукта с продуктами конкурентов
    0
    А вы попробуйте от обратного. Когда ваши продажники связываются с интересующими вас компаниями, чтобы обсудить сотрудничество, они вполне могут спросить каким сейчас альтернативным ИТ-продуктом они пользуются и с кем по решению проблемы/потребности сотрудничают.

    Если компания не с нами, а она либо сама пытается решать проблему либо кто-то другой ей в этом помогает.
  • Гибкое планирование выпуска релизов 101 (на основе Excel)
    0
    NeverIn вам этот комментарий нужно оставить на английском языке в блоге Tommy Norman-а.

    А багами занимается отдельная команда?

    В оригинальной статье говорится что багами занимается та же самая команда. Автор говорит что чаще встречает два варианта.

    Первый — что кто-то из разработчиков узнаёт что это «его» (он разрабатывал то, что выдаёт ошибку) и забирает этот баг в свой персональный список, выделяя на их устранение определенное количество времени на цикл разработки (Sprint).

    Второй — что они добавляются в общей список (Product Backlog) и команда тратит общее время на цикл разработки, чтобы устранить те из них, чтобы были добавлены в Sprint Backlog.

    По какому принципу оценивается estimate бага?

    Если баги добавляются в Product Backlog также как User Story в момент старта, когда Product Backlog-а ещё нет, то в этом случае оценка будет происходить по тем же принципам что и весь список. Сперва: smal, medium, big. Затем уже используются цифровые оценки.

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

    На что Автор обращает особое внимание, что те с кем ему доводилось работать сперва настаивали на том, чтобы проанализировать баг, чтобы понять что не так, перед тем как давать какую-то оценку.
  • Продолжаем настраивать практически бесплатную рекламу на пользователей Хабра. На этот раз с помощью виджета авторизации
    0
    Есть две точки зрения.

    Хабровчан
    Она говорит, что нам это нужно, поэтому +41 и индекс добавления в избранное больше 1%.
    Есть желание это попробовать-проверить. Ваши умения интересны-полезны.

    Хабровласти
    Думаю и они думают уже над тем, как с этой «фитчей» быть, какие есть варианты. Эта фитча «убивает» источники дохода, которые питают Хабр. Если это не лечить, то так можно дожить до платной подписки на хабр иначе он накроется тазиком и придется как недавно с Луркоморьем собирать всем миром.
  • Продолжаем настраивать практически бесплатную рекламу на пользователей Хабра. На этот раз с помощью виджета авторизации
    +1
    Денис, у вас отличная статья.

    Если бы вы ссылку на телеграмм не делали, а разместили бы её в профиле и Авторской подписи под статьёй, у Администрации не было бы к вам никаких вопросов.



    А так вы нарушили правило Рекламировать собственные ресурсы в обход правил.
    И в соответствии с ними вашу статью отправили в «Я пиарюсь» и, похоже, включили для вас опцию «тереть комментарии» пока вы не остынете. Комментарий вышел эмоциональным.
  • Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)
    0
    Благодарю вас и Rampages за аргументированную обратную связь.

    Статья получилась полярной, по состоянию на 11:00 20.11.16, 31% голосующих читателей оценили её отрицательно, а некоторые снабдили и «подзатыльником», но не сопроводили комментарием.
    Это указывает на то, что есть что обсудить и это точно не стоит игнорировать, чтобы не получить в будущем.

    Вариант

    — За что???
    — Было бы за что вообще убил бы!

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

    Про картинки

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

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

    Про ничего полезного и отняла ощутимое время

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

    Что у вас за ситуация-проблема, которая побудила вас отправиться под кат?

    Минус я получил за то, что не оправдал ожиданий. Дайте мне ещё один шанс назвав свою ситуацию-проблему, вдруг у меня есть чем с вами поделится.

  • Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)
    0
    Ребята, хабровчане, обращаюсь к тем из вас, кому статья не понравилась и вы даже хотите или уже заминусовали мне карму.

    Оставьте комментарий, что вам так сильно не понравилось, что вы решили не ограничиваться только минусом к статье.
  • Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)
    +2
    К принципам:
    • слушать и слышать
    • не навреди
    я добавлю «проявлять любопытство и ковырять».

    Если упростить, компания приглашая консультантов ожидает получить знания которых у неё нет. Это:
    1. глубокое знание предмета (экспертиза)
    2. как устроены процессы у конкурентов и показатели их эффективности (делают ли они свой продукт лучше чем мы, тратя меньше ресурсов и более качественно)
    3. обобщенный мировой опыт лучших практик (то что предлагает ребята из большой 4-ки)
    4. комплексное виденье (где во всей цепочке узкие места, так как в них нужно бить чтобы повысить мощность всей цепочки)

    Я думал над тем как извлечь из консультантов пользу так как то, что мы ждали и то, что мы получали порой не совпадали. Вот некоторые из выводов:

    «глубокое знание предмета»
    Лучше получать и искать на хабре.
    Опубликовав свой кейс, есть высокая вероятность получить в комментариях содержательную обратную связь. Комментарии выводят на практикующих экспертов с которыми уже можно общаться лично.
    Также работает и поиск по опубликованным аналогичным кейсам выводя на нужных экспертов.

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

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

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

    Но Консультанты нужны и очень в следующих ситуациях:
    • при попытке разобраться с передовой технологией, у которой ещё нет массового применения (думаю отсюда и вырос весь консалтинговый бизнес, когда на деревне есть только один Мастер).
    • когда нужно освоить какие-то специфические инструменты и сделать это быстро.
  • Каким должно быть ТЗ на Корпоративную ИС?
    0
    Да, вы верно ухватили суть и процесс.

    Добавлю ещё пару уточняющих моментов.

    Момент №1

    Если функционал новый

    После того как новый бизнес-процесс спроектирован и наложен на текущий интерфейс Приложения, Заказчик отключается от данного процесса и включается в работу Системный Аналитик.

    Системный аналитик формулирует перечень проблем: что надо добавить и изменить. На основе подготовленного документа он общается с Архитектором и Разработчиков как они будут решены и добавляет ответы на вопросы к сформулированным проблемам, переводит их в задачи.

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

    На этом этапе согласования подключается Тестировщик и вместе с Системным Аналитиком готовит сценарии тестирования.

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

    Если функционал не новый

    Изменения в реализованный бизнес-процесс Бизнес-аналитик вносит через документ «Дополнение к ТЗ», который указывает какой раздел описания бизнес-процесса изменяется и на что.
    И далее по цепочке, подключается Системный аналитик и анализирует новые требования к Приложению.


    Момент №2

    Наличие «картинок и кнопок» в ТЗ делает описание бизнес-процесса для Заказчика похожим на правду. Из абстрактного, описание превращается в конкретное.

    Сравните
    Создаёт в системе новое поручение через специальную экранную форму.

    И

    Нажимает на кнопку «Создать новое поручение»,

    на открывшейся форме «Нового поручения»
    сотрудник ОККЭ заполняет поля …

    Если Пользователь уже знает интерфейс системы, то для него такое описание выглядит ещё более правдивым.

    Когда ТЗ содержит много абстракций и они ссылаются друг на друга, Пользователи теряют общее видение решения и отсюда «прилетают» ошибки в логике работы, которые хуже ошибок в коде. Ошибку в коде можно быстро поправить, а ошибку в реализованной логике может и не получится быстро устранить.
  • Каким должно быть ТЗ на Корпоративную ИС?
    0
    Комментарий Кирилла навел меня на ряд размышлений, что вылилось в не короткий ответ (читать ниже), который лучше раскрывает поднятую тему.
    Locolind, 7 ноября в 22:31
    Добрый вечер, Кирилл.

    Благодарю за комментарий к статье «Каким должно быть ТЗ?» у меня займёт некоторое время подготовить для вас ответ.
    Хочу уточнить у вас, какие разделы показались вам лишними / не нужными в нашем шаблоне ТЗ?
    И если есть возможность, то дайте комментарий почему считаете его лишним.

    Askofen, 9 ноября в 01:13
    Добрый вечер, Максим!

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

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

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

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

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

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

    По этой причине описывать работу Корпоративной ИС лучше с точки зрения бизнес-процесса, а не функциональных возможностей системы.
    Когда описываешь КИС с позиции рабочего процесса ТЗ начинает сильно быть похожим на руководство пользователя, охватывая работу разных типов пользователей в ней. Те участки, что не покрывались текущим решением отражались на схеме и в описании как выполняемые без КИС. Это служит целеуказателем куда дальше развивать ИТ-решение.
    Полученный документ это:
    • на 80% готовое руководство пользователя, его остается сгруппировать и структурировать по ролям/группам пользователей.
    • готовые сценарии для функционального тестирования.


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

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

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

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

    Вторая причина – ему не дадут это сделать после, а не до. Система находится под большой нагрузкой, переваривает 60 миллиардов рублей в год, в день это 170 мил. рублей в день. В ней работает более 2000 пользователей. Простой системы – это финансовые потери и последующие «перегрузки» в работе компании, так как выпавший в работе день нужно будет нагонять. Есть понимание что “time to market” должен быть минимален на столько на сколько это возможно, но при условии, что риск будет сопоставим с получаемой выгодой. Если риск убытков высок, а выгода не покрывает их, то мы склоны сперва спроектировать новый бизнес процесс, посмотреть как мы будем работать на тестовой среде и только после этого ставить обновление на промышленную систему и проводить изменение в бизнес-процессах компании.
    Мы придерживаемся той точки зрения, что результат нашей работы — это готовая программа, а не техническое задание.

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

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

    Мне кажется, вы смотрите на неё только с точки зрения Разработчика.
    Основание для разработки – это для Аудита, чтобы связать то что сделано (на что были потрачены ресурсы) с бизнес-запросами (обоснованием этих затрат).
    Тема разработки и бизнес-процесс предназначены для Бизнес-аналитика по направлению, чтобы внести данные в реестр ТЗ и в последующем осуществлять навигацию и поиск нужных ТЗ.
    Постановка задачи, задачи и цель также предназначены для Бизнес-аналитика, чтобы быстро «считать» о чем ТЗ, что им реализовано.
    Охваченные компоненты – это для Архитектора и Системного Аналитика, чтобы быстро «считать» есть ли интеграция с чем-то ещё или всё в рамках одной ИС.
    Этапы внедрения – это для Заказчика и Руководителя ДИТ фиксирующие факт окончания работ и подтверждения, что решение принято Заказчиком.
    Думаю, что документ можно разделить на 2 документа или на 2 части.

    Документ поделен на две части, то что вы видите это бизнесовая часть, а есть ещё техническая, которую бизнес-пользователи не видят и которую пишет системный аналитик для разработчиков. В ней он каждое «Нажал на кнопку, появилась форма для заполнения Такая-то» переводит в список задач что нужно сделать и что изменить. Бизнесовая часть не указывает есть ли эта кнопка, появляется ли в результате нажатия именно эта форма. Бизнесовая часть — это чистая фантазия Пользователя/Заказчика и Бизнес-аналитика на тему как будет выглядеть выполнение бизнес-операции в системе.

    Бизнесовая часть также состоит из двух частей «Тела» и «Приложений».
    В Приложения выносятся формы Отчетов, описание Алгоритмов и всё подобное.
    Также в Вашем образце мне кажутся лишними упоминания нажатий на кнопочки и похожая детализация. 
    В первом документе (или в первой части) достаточно дать описание бизнес-процесса. При этом, графическое представление имеет преимущество над текстовым. И текст не должен просто дублировать рисунок. В тексте нужно указать лишь то, что невозможно отобразить на диаграмме.

    За излишней детализацией незримо присутствует нотация IDEF0 (SADT), которая говорит, что у действия есть вход, выход, кто это действие выполняет, инструменты и управление. Мы дополняем вход указанием от кого кому, откуда куда, так как описание текстовое.
    В таком виде документ поступает на вход бизнес-аналитику, и он готовит второй документ (или вторую часть документа), в которой рисует screen-flow и мокапы экранов.

    1. А почему вы этого сотрудника называете бизнес-аналитиком, а не системым аналитиком?
    2. И кто тогда готовит тот документ, который поступает на вход «бизнес-аналитику»?

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

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

    Проектирование бизнес-процесса на системе одновременно «заземляет» Бизнес-аналитика и Пользователя минимизируя разрыв между тем, что хочется и тем что есть сейчас.

    Так решается проблема, что ребята могут придумать новый концепт, который в корне отличается от существующего, разработаны новые регламенты и подготовлено ИТ-решение, но им просто Страшно переходить на новую схему, так как никто в ней не умеет работать, полное виденье есть у Начальника и Проектировщика, но им страшно не меньше чем всем остальным. Страх нагоняет упоминавшийся выше контекст, что подразделение находится под существенной нагрузкой и они не готовы к возможным не предвиденным остановкам. Поэтому здесь работает стратегия эволюционных изменений в сторону нового концепта.  
  • О рабах, героях и рабах-героях
    0
    Есть ещё другая ситуация из моего жизненного опыта:

    Ты делаешь хорошо на протяжении нескольких лет, но тут вдруг высокий начальник меняется.
    Он приходит и говорит: «Ребята, всё что вы тут создавали несколько лет, это фигня. Мы это выбрасываем и теперь вместо этого будет вот это». И это сразу отбрасывает всех на несколько лет назад…

    При этом:
    — платят в рынке;
    — скилл-ы у команды выросли;
    Как итог — задачи мы решаем быстро и эффективно, но мотивации делать это ещё быстрее и лучше нет, так как завтра это могут вновь уничтожить.

    Чем то это похоже с ситуацией когда пишешь текст (письмо, свой вариант...), накатал страницы на две-три и тут вырубают свет, а ты при этом не делал резервную копию…
  • О рабах, героях и рабах-героях
    –3
    Энтузиаст — это человек со внутренней мотивацией, делающий какое-то значимое для общества дело по собственной инициативе, в силу внутренних убеждений, без получения прямой выгоды.

    Если этот человек в своём деле при этом эффективен и результативен, то он уже не Энтузиаст, это Герой.
    Эффективность и результат указывают на то, что среда меняется.

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

    Данное вами определение Энтузиаста верно и именно в этом оно совпадает с определением Автора.
    Результата нет, но внутреннее желание и, возможно, какая-то активность сделать что-то полезное для общества есть.
  • О рабах, героях и рабах-героях
    +5
    Согласен с вами, что в последнее время бестолковых и высосанных из пальца статей становится больше, чем то напоминая студенческую историю с курсовыми, которые все больше не анализ, а компиляция чужих мыслей.
    Эта статья на них не похожа, здесь есть оригинальный сюжет и новизна.

    Взгляните на это как на личный поиск, попытку разобраться в предмете.
    Через такой же путь прошла Биология в своё время (отсылка к Дарвину «Происхождение видов», но были и попытки до него).
    И Астрономия — Н.Коперник, Д.Бруно…

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

    Автор знаком с историей (только за это уже заслуживает плюса) и оперирует определенными артефактами (Греческий Герой, Картожане, Рабы, Пленные...) накладывает их на линию «Труд/Работа» и пытается понять в чем Мотивация каждого из Артефактов трудится эффективно.
    Результаты этого исследовательского труда оформлены в статью и ещё и иллюстрированы для облегчения восприятия (это повод для ещё одного плюса).
  • Сделать завтра. Как не тратить время на мелочи
    +1
    Владимир, благодарю за статью.
    Понравилась. Делюсь с вами статьёй своего знакомого Дмитрия Тарасова.
    «Почему в основе продуктивности лежит управление энергией, а не временем»
    Я дополнил его статью своим развернутым комментарием про физический и ментальный тонус, что они также нужны, чтобы быть продуктивным.

    Также Дмитрий выпустил своё приложение Хаос контроль для работы с задачами.
  • Управление задачами на разработку. История из жизни
    0
    Каждый тратит свои деньги так как считает нужным. Статья о том, как деньги считать и вкладывать с отдачей.


    Если денег много, можно всю 1000 задач по 1000 рублей сделать, за этим прилетит ещё 1000 по 1000, из которых 500 будет переделать то, что сделали раньше, либо чтобы вернуть как было либо потому что надо по другому.

    Но в целом ваш вариант вполне рабочий, посадили программиста со знанием предметной области в «песочницу» и там он с Заказчиком что-то лепит.

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

    дизлайк получить от бизнеса

    Когда денег в компании станет меньше, а привычка получать от ИТ всё что хочется останется, у вас начнет бэк-лог увеличиваться, а вот новых ресурсов вам не дадут, так как денег нет в компании.
    Вы и придёте к описанной ситуации, что вы делаете что-то полезное для бизнеса, а вам говорят что этого мало и медленном, получите дизлайки от бизнеса.
    Что что-то нужно менять.
  • Управление задачами на разработку. История из жизни
    0
    Группировать по заказчикам и/или объектам, которые требуется доработать.

    А далее как в приведенном комментарии
    https://habrahabr.ru/post/314448/#comment_9897288

    Можно не кидаться делать эти мелкие задачи сразу, как только они возникнут, а собрать в «пачку», сделать ТЭО для «пачки» и уже принимать решение на основе дроби Эффективность/Затраты.
  • Управление задачами на разработку. История из жизни
    +1
    С таким подходом можно влипнуть в типичные проблемы иерархических систем: задержки управлющих сигналов, показуха, неэффективность.

    Вы правы, мы столкнулись с торможением и пошли по пути который вы предложили.
    Выглядел он в двух словах так:
    • Задачи стоимостью до 500 тысяч рублей согласовывает Начальник отдела.
    • От 500 тысяч до 1 млн. рублей заместитель директора департамента, заказывающего бизнес-подразделения.
    • От 1 млн. рублей до 3 млн.рублей директор департамента.
    • Свыше 3 млн. рублей контроль на уровне заместителей генерального директора, курирующих бизнес-блок.

    Заместителю генерального директора некогда и неинтересно согласовывать доработку формочки за 100 000 рублей.
    Если есть ТЭО и оно говорит, что её выгодно дорабатывать, ему этого достаточно.
    То что выгода будет достигнута, проверит Внутренний Аудит.
    Если не будет достигнута, Заказчика наказать не накажут, но проверят окупится ли хотя бы и возьмут на заметку.
  • Управление задачами на разработку. История из жизни
    0
    В этом и беда: IT совсем не понимают как работает бухгалтерия, которую они пытаются автоматизировать


    Если развивать мысль, то ИТ нужно будет отправить и в продажи и в маркетинг и в логистику… во все бизнес-подразделения понимать как они работают и какие операции какой сложностью и трудоемкостью обладают.

    Мне хочется уберечь Разработчиков от этих «душевных травм и драм» и отправлять в бизнес-подразделения Бизнес-аналитиков, чтобы они делили боль Заказчиков из бизнес-подразделений.

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

    Не поспоришь, всё что отнимает чудовищное количество времени у сотрудников нужно изучать и думать можем ли мы эти затраты уменьшить.
    И делать это не только из чувства сострадания бухгалтеру, но и потому что это выгодно.
  • Управление задачами на разработку. История из жизни
    +1
    Скорее всего, на нижнем уровне при таком подходе начинается саботаж новых продуктов и все возвращается обратно в Exсel.


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

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

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

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

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