Если упростить, компания приглашая консультантов ожидает получить знания которых у неё нет. Это:
глубокое знание предмета (экспертиза)
как устроены процессы у конкурентов и показатели их эффективности (делают ли они свой продукт лучше чем мы, тратя меньше ресурсов и более качественно)
обобщенный мировой опыт лучших практик (то что предлагает ребята из большой 4-ки)
комплексное виденье (где во всей цепочке узкие места, так как в них нужно бить чтобы повысить мощность всей цепочки)
Я думал над тем как извлечь из консультантов пользу так как то, что мы ждали и то, что мы получали порой не совпадали. Вот некоторые из выводов:
«глубокое знание предмета»
Лучше получать и искать на хабре.
Опубликовав свой кейс, есть высокая вероятность получить в комментариях содержательную обратную связь. Комментарии выводят на практикующих экспертов с которыми уже можно общаться лично.
Также работает и поиск по опубликованным аналогичным кейсам выводя на нужных экспертов.
«как устроены процессы у конкурентов и показатели их эффективности»
Консультанты работают как испорченный телефон. Для себя выяснил, что более эффективный способ это ходить на тематические мероприятия, где коллеги из отрасли (конкуренты), что-то о себе рассказывают и с ними лично уже более детально обсуждать их рабочие процессы.
«обобщенный мировой опыт лучших практик»
Здесь консультанты дают пользу, так как и мы и они, вместе берем какой-то любопытный материал, который им достался от головной компании, и примеряем его на нашу компанию.
Так как для ребят примерка этих «практик» ежедневная работа, а для нас единовременная активность, они в этом разбираются лучше.
«комплексное виденье»
Плохо получается у ребят, либо слишком абстрактно либо слишком узко-«в лоб».
А даже когда у ребят выходит хороший продукт, его Потребители (Руководство), порой не в состоянии его потребить.
За «комплексным виденьем» лучше не к консультантам, а руководителей отправлять в бизнес-школу.
Но Консультанты нужны и очень в следующих ситуациях:
при попытке разобраться с передовой технологией, у которой ещё нет массового применения (думаю отсюда и вырос весь консалтинговый бизнес, когда на деревне есть только один Мастер).
когда нужно освоить какие-то специфические инструменты и сделать это быстро.
После того как новый бизнес-процесс спроектирован и наложен на текущий интерфейс Приложения, Заказчик отключается от данного процесса и включается в работу Системный Аналитик.
Системный аналитик формулирует перечень проблем: что надо добавить и изменить. На основе подготовленного документа он общается с Архитектором и Разработчиков как они будут решены и добавляет ответы на вопросы к сформулированным проблемам, переводит их в задачи.
Решения показываются Бизнес-аналитику, он их проверяет на соответствие целям и результатам бизнес-операций. Если технические ограничения не позволяют реализовать бизнес-процесс в заявленном виде, уже отталкиваясь от текущих возможностей Бизнес-аналитик готовит новый вариант выполнения бизнес-операции и согласовывает с Заказчиком.
На этом этапе согласования подключается Тестировщик и вместе с Системным Аналитиком готовит сценарии тестирования.
Документ, разработанный Системным аналитиком, и всё что готовится дальше Заказчику не показывается. Заказчик получает подтверждение Бизнес-аналитика, что Приложение будет обеспечивать новый вариант бизнес-процесса, Заказчик подтверждает, что мы можем начинать реализацию.
Если функционал не новый
Изменения в реализованный бизнес-процесс Бизнес-аналитик вносит через документ «Дополнение к ТЗ», который указывает какой раздел описания бизнес-процесса изменяется и на что.
И далее по цепочке, подключается Системный аналитик и анализирует новые требования к Приложению.
Момент №2
Наличие «картинок и кнопок» в ТЗ делает описание бизнес-процесса для Заказчика похожим на правду. Из абстрактного, описание превращается в конкретное.
Сравните Создаёт в системе новое поручение через специальную экранную форму.
И
Нажимает на кнопку «Создать новое поручение»,
на открывшейся форме «Нового поручения»
сотрудник ОККЭ заполняет поля …
Если Пользователь уже знает интерфейс системы, то для него такое описание выглядит ещё более правдивым.
Когда ТЗ содержит много абстракций и они ссылаются друг на друга, Пользователи теряют общее видение решения и отсюда «прилетают» ошибки в логике работы, которые хуже ошибок в коде. Ошибку в коде можно быстро поправить, а ошибку в реализованной логике может и не получится быстро устранить.
Комментарий Кирилла навел меня на ряд размышлений, что вылилось в не короткий ответ (читать ниже), который лучше раскрывает поднятую тему.
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 и мокапы экранов.
А почему вы этого сотрудника называете бизнес-аналитиком, а не системым аналитиком?
И кто тогда готовит тот документ, который поступает на вход «бизнес-аналитику»?
Сложилось впечатление, что вы так разводите два этапа работ, описание бизнес-процесса и проектирование программы.
В нашем случае мы сразу проектируем бизнес-процесс визуализируя его на системе. То что нам может не хватить технических возможностей, Бизнес-аналитика и Пользователя этим не заморачиваем, пусть рисуют концепт. Дальше в момент анализа и проектирования технических решений станет ясно, что можем, а что не можем и какую альтернативу будем предлагать Пользователю, чтобы обеспечить тот же результат выполнения бизнес-операции.
Проектирование бизнес-процесса на системе одновременно «заземляет» Бизнес-аналитика и Пользователя минимизируя разрыв между тем, что хочется и тем что есть сейчас.
Так решается проблема, что ребята могут придумать новый концепт, который в корне отличается от существующего, разработаны новые регламенты и подготовлено ИТ-решение, но им просто Страшно переходить на новую схему, так как никто в ней не умеет работать, полное виденье есть у Начальника и Проектировщика, но им страшно не меньше чем всем остальным. Страх нагоняет упоминавшийся выше контекст, что подразделение находится под существенной нагрузкой и они не готовы к возможным не предвиденным остановкам. Поэтому здесь работает стратегия эволюционных изменений в сторону нового концепта.
Есть ещё другая ситуация из моего жизненного опыта:
Ты делаешь хорошо на протяжении нескольких лет, но тут вдруг высокий начальник меняется.
Он приходит и говорит: «Ребята, всё что вы тут создавали несколько лет, это фигня. Мы это выбрасываем и теперь вместо этого будет вот это». И это сразу отбрасывает всех на несколько лет назад…
При этом:
— платят в рынке;
— скилл-ы у команды выросли;
Как итог — задачи мы решаем быстро и эффективно, но мотивации делать это ещё быстрее и лучше нет, так как завтра это могут вновь уничтожить.
Чем то это похоже с ситуацией когда пишешь текст (письмо, свой вариант...), накатал страницы на две-три и тут вырубают свет, а ты при этом не делал резервную копию…
Энтузиаст — это человек со внутренней мотивацией, делающий какое-то значимое для общества дело по собственной инициативе, в силу внутренних убеждений, без получения прямой выгоды.
Если этот человек в своём деле при этом эффективен и результативен, то он уже не Энтузиаст, это Герой.
Эффективность и результат указывают на то, что среда меняется.
Например, есть пруд.
Если его не чистить и не сделать систему отвода воды, вода будет стоять и он превратится в болото.
Если человек чистит пруд от тины и зарослей, а также сделал отвод воды, она стала проточной, сделал это по внутренней мотивации не на заказ, то для тех кто этим прудом пользуется (купается, ловит рыбу...) и «понимает», что это результат чьего-то труда, для них он Герой.
Данное вами определение Энтузиаста верно и именно в этом оно совпадает с определением Автора.
Результата нет, но внутреннее желание и, возможно, какая-то активность сделать что-то полезное для общества есть.
Согласен с вами, что в последнее время бестолковых и высосанных из пальца статей становится больше, чем то напоминая студенческую историю с курсовыми, которые все больше не анализ, а компиляция чужих мыслей.
Эта статья на них не похожа, здесь есть оригинальный сюжет и новизна.
Взгляните на это как на личный поиск, попытку разобраться в предмете.
Через такой же путь прошла Биология в своё время (отсылка к Дарвину «Происхождение видов», но были и попытки до него).
И Астрономия — Н.Коперник, Д.Бруно…
Кстати о последнем, сейчас то что происходит по отношению к автору и его статье очень походит на историю с судом инквизиции.
Будто мы знаем в чем Истина-Правда, а автор статьи ошибается, поэтому мы его минусуем.
Автор знаком с историей (только за это уже заслуживает плюса) и оперирует определенными артефактами (Греческий Герой, Картожане, Рабы, Пленные...) накладывает их на линию «Труд/Работа» и пытается понять в чем Мотивация каждого из Артефактов трудится эффективно.
Результаты этого исследовательского труда оформлены в статью и ещё и иллюстрированы для облегчения восприятия (это повод для ещё одного плюса).
Владимир, благодарю за статью.
Понравилась. Делюсь с вами статьёй своего знакомого Дмитрия Тарасова. «Почему в основе продуктивности лежит управление энергией, а не временем»
Я дополнил его статью своим развернутым комментарием про физический и ментальный тонус, что они также нужны, чтобы быть продуктивным.
Также Дмитрий выпустил своё приложение Хаос контроль для работы с задачами.
Каждый тратит свои деньги так как считает нужным. Статья о том, как деньги считать и вкладывать с отдачей.
Если денег много, можно всю 1000 задач по 1000 рублей сделать, за этим прилетит ещё 1000 по 1000, из которых 500 будет переделать то, что сделали раньше, либо чтобы вернуть как было либо потому что надо по другому.
Но в целом ваш вариант вполне рабочий, посадили программиста со знанием предметной области в «песочницу» и там он с Заказчиком что-то лепит.
Если нужны какие-то сквозные изменения затрагивающие работу нескольких подразделений, ваш вариант потребует усложнений и изменения «архитектуры» системы, при этом в последующем ваш программист не может менять тот «кирпич», который у него отмечен, что им пользуется соседнее подразделение.
Для этого придется с ним договорится об изменениях в нём.
дизлайк получить от бизнеса
Когда денег в компании станет меньше, а привычка получать от ИТ всё что хочется останется, у вас начнет бэк-лог увеличиваться, а вот новых ресурсов вам не дадут, так как денег нет в компании.
Вы и придёте к описанной ситуации, что вы делаете что-то полезное для бизнеса, а вам говорят что этого мало и медленном, получите дизлайки от бизнеса.
Что что-то нужно менять.
Группировать по заказчикам и/или объектам, которые требуется доработать.
А далее как в приведенном комментарии
https://habrahabr.ru/post/314448/#comment_9897288
Можно не кидаться делать эти мелкие задачи сразу, как только они возникнут, а собрать в «пачку», сделать ТЭО для «пачки» и уже принимать решение на основе дроби Эффективность/Затраты.
С таким подходом можно влипнуть в типичные проблемы иерархических систем: задержки управлющих сигналов, показуха, неэффективность.
Вы правы, мы столкнулись с торможением и пошли по пути который вы предложили.
Выглядел он в двух словах так:
Задачи стоимостью до 500 тысяч рублей согласовывает Начальник отдела.
От 500 тысяч до 1 млн. рублей заместитель директора департамента, заказывающего бизнес-подразделения.
От 1 млн. рублей до 3 млн.рублей директор департамента.
Свыше 3 млн. рублей контроль на уровне заместителей генерального директора, курирующих бизнес-блок.
Заместителю генерального директора некогда и неинтересно согласовывать доработку формочки за 100 000 рублей.
Если есть ТЭО и оно говорит, что её выгодно дорабатывать, ему этого достаточно.
То что выгода будет достигнута, проверит Внутренний Аудит.
Если не будет достигнута, Заказчика наказать не накажут, но проверят окупится ли хотя бы и возьмут на заметку.
В этом и беда: IT совсем не понимают как работает бухгалтерия, которую они пытаются автоматизировать
Если развивать мысль, то ИТ нужно будет отправить и в продажи и в маркетинг и в логистику… во все бизнес-подразделения понимать как они работают и какие операции какой сложностью и трудоемкостью обладают.
Мне хочется уберечь Разработчиков от этих «душевных травм и драм» и отправлять в бизнес-подразделения Бизнес-аналитиков, чтобы они делили боль Заказчиков из бизнес-подразделений.
Переодические отчеты, в то числе годовые могут отнимать чудовищное количество времени у бухгалтера и их сведение это одна из важнейших операций.
Не поспоришь, всё что отнимает чудовищное количество времени у сотрудников нужно изучать и думать можем ли мы эти затраты уменьшить.
И делать это не только из чувства сострадания бухгалтеру, но и потому что это выгодно.
Скорее всего, на нижнем уровне при таком подходе начинается саботаж новых продуктов и все возвращается обратно в Exсel.
Личное наблюдение.
Там где начинается саботаж новых продуктов, эти компании начинают проигрывать конкурентную борьбу. Вопрос в том на сколько хватит прочности у организации.
Там где в компаниях экспериментируют и пробуют что-то новое, случаются и инсайты и кратный рост эффективности, работать и интересно и платят хорошо, так как есть из чего платить.
Из моего опыта лучшее решение, это отправить программистов на неделю в бухгалтерию и заставить их пользоваться своими творениями. Обычно после этого у них на многие «ненужные» задачи внезапно появляется другой взгляд.
Похоже на то, что программисты получают новую квалификацию «Бизнес-аналитиков» и для них задачи перестают быть «обезличенными», они понимают для кого и что они делают, удобно ли этим пользоваться и есть ли эффект.
Ваш посыл мне в целом понятен.
Добавил бы что «рыба гниёт с головы», но часто не в наших силах заменить Руководителя в подразделении.
В моем случае это сводилось к тому, что я начинал выбирать «вменяемых» внутренних Заказчиков, которым была нужна возможность. Работа с ними, со временем, начинает отрезвлять окружающую обстановку и подтягиваются другие адекватные заинтересованные лица.
Кстати, вы извините, но пример ТЭО некорректный — классический пример манипулирования цифрами. Хуже только «повышение прозрачности» и прочая демагогия.
Вы меня ничуть не задели и у нас не просто спрашивали сколько человек сокращаем, а пытались сокращать.
И если сотрудников не сокращали, то спрашивали куда ушла экономия.
В результате это стало сильным мотиватором для бизнеса начать использовать JIRA в своей работе, чтобы ответ на этот вопрос был прозрачен / оцифрован.
Если в компании никто не проверяет достигнут ли был результат, то вы правы люди только научаться манипулировать цифрами и уметь с их помощью обосновывать свои задачи.
Это уже полшага вперёд.
Здесь есть два варианта, что будет дальше. Мы использовали оба.
Первый — Руководство перестало давать ресурсы подразделениям на прямую. То есть для достижения увеличившихся показателей вы не можете получить ещё людей, ищите возможность повысить внутреннюю эффективность.
Например, нужно сделать уже не 10 продаж, а 20. Простой вариант, нанять ещё продавцов, а сложный это работать с воронкой продаж, конверсией и что-то оптимизировать в своей текущей работе, чтобы это время на работу с воронкой продаж и конверсией появилось.
Второй — у нас Внутренний Аудит получил новое поле для своей работы. Замерять «до» и «после».
Где-то справлялись хорошо и без него, где-то он учил руководителей считать и замерять.
Но от четверти выполненных задач будет хоть какая-то отдача.
Она будет скорее эмоциональная, чем экономическая.
Вам будут благодарны за то, что вы сделали, но вот сколько выгоды в рублях и есть ли она это неизвестно.
При этом будет то что можно точно замерить, это сколько времени было затрачено на их реализацию, и сколько вы должны получить в кассе предприятия.
Затраты, которые будут профинансированы из прибыли компании.
Представьте, что и Продавцы в компании будут работать также. Не оценивать привлекательность клиентов, а продавать каждому желающему по одной ручке за 1 рубль, затрачивая на это по 2-3 дня своего рабочего времени на сделку. Долго такой бизнес не протянет.
Какая отдача от от толстой пачки отрицательных ТЭО
В компании появляется навык считать деньги / быстро делать разумное ТЭО
Компания перестает разбрасываться деньгами и сосредотачивается на действительно выгодных и ценных задачах
у вас появляется время на того, чтобы прочесть книгу или поучится каким-то интересным и новым технологиям, которые повысят эффективность вашей работы вместо того чтобы тратить деньги компании на то что имеет неподтвержденную ценность.
настолько повысит их стоимость (это же тоже не бесплатный процесс), что они станут невыгодными
Если после составления ТЭО задачу становится не выгодно делать, то ее уже можно не делать.
Цель ТЭО — остановить поток таких мелких, которых делать нельзя, задач так как польза для компании от них либо минимальна либо вообще никакой, если они даже затрат на составление ТЭО не окупают. И сосредоточить имеющиеся ресурсы на тех задачах, которые будут приносить максимальную отдачу для Компании и Клиентов.
Пример.
Задача №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-а.
Если этого не делать, мы чаще будем «жечь» дефицитные и дорогостоящие ресурсы разработки в пустую, чем создавать что-то реально ценное.
Не смогу ответить на ваш вопрос. Был не с самого начала появления нашей системы.
Пришел работать в компанию уже после того, как ребята съездили в командировку, CRM-система была закуплена и развернута, начат процесс по её доработке/развитию.
У нас был и электронный и бумажный архив документации на систему. Последний ведется по той причине, что компания каждый год проходит проверку Генеральной Прокуратурой и Счетной Палатой на предмет целевого расходования средств, так как основной акционер компании Государство.
Их интересует:
— кто авторизовал расходование средств на ИТ-систему,
— на что они пошли и зачем это было нужно,
— кто делал / кто получил деньги,
— кто осуществлял приемку.
в 2014 году начали экспериментировать с Электронно-Цифровой Подписью для взаимодействия внутри и с Партнерами, чтобы отказаться от бумажного документооборота в пользу юридически значимого электронного.
Погуглил.
Так как у меня остались смутные воспоминания, со времен изучения SADT, что в Америке в 70-е годы документация на ИТ-системы доходила до нескольких тон, если это касалось систем масштаба страны.
Structured Analysis and Deign Technique появилась в 1969-1973 году.
Упомянутые здесь в комментариях GIT и SVN появились в 2000-е.
CVS первый выпуск 1990.
Freddie Mac появилась в 1970 году.
в 2006 году оборот компании 44 млрд. долларов.
Активы в 2015 году 1,946 трлн. долларов.
Fannie Mae появилась в 1938 году.
Активы в 2014 году 3,2 трлн. долларов.
Даты создания компаний, масштаб бизнеса, дата появления SADT и даты появления систем управления версиями указывают на то, что у каждой ТЗ на ERP-систему могло быть больше чем в 3 шкафа.
Сколько вас ждет усилий и времени я могу представить, у нас самих ушло несколько лет на то, чтобы переработать ИТ-решение. Дело ли мы это совмещая «апгрейд» старых фич и создавая новые, без открытия специальных проектов рефакторинга под это.
Тоже написал статью про наш «legacy» проект на днях.
Так как был руководителем проектов, то начали раскручивать клубок через технические задания. Приводя в порядок их и те куски, что им соответствовали внутри.
В нашем случае Проблема выглядела так, когда мы делали что-то одно, у нас отваливалось в нескольких других местах. У Заказчика сложилось впечатление что «Нормально» сделать с первого раза мы ничего не можем. Причина её заключалась «в сплошном коде», в котором было непонятно где заканчивается одна фича и начинается новая, и задача была разметить его на «функциональные области».
UPD. «Сплошной код» это была не вина Разработчиков, так как система изначально была коробочной и для настройки, а не для того чтобы на её основе разрабатывать отраслевое ИТ-решение.
Прошу простить мой технический русский, не разработчик, это мой обывательский взгляд РП-БА на ИТ-систему.
Оставьте комментарий, что вам так сильно не понравилось, что вы решили не ограничиваться только минусом к статье.
- слушать и слышать
- не навреди
я добавлю «проявлять любопытство и ковырять».Если упростить, компания приглашая консультантов ожидает получить знания которых у неё нет. Это:
Я думал над тем как извлечь из консультантов пользу так как то, что мы ждали и то, что мы получали порой не совпадали. Вот некоторые из выводов:
«глубокое знание предмета»
Лучше получать и искать на хабре.
Опубликовав свой кейс, есть высокая вероятность получить в комментариях содержательную обратную связь. Комментарии выводят на практикующих экспертов с которыми уже можно общаться лично.
Также работает и поиск по опубликованным аналогичным кейсам выводя на нужных экспертов.
«как устроены процессы у конкурентов и показатели их эффективности»
Консультанты работают как испорченный телефон. Для себя выяснил, что более эффективный способ это ходить на тематические мероприятия, где коллеги из отрасли (конкуренты), что-то о себе рассказывают и с ними лично уже более детально обсуждать их рабочие процессы.
«обобщенный мировой опыт лучших практик»
Здесь консультанты дают пользу, так как и мы и они, вместе берем какой-то любопытный материал, который им достался от головной компании, и примеряем его на нашу компанию.
Так как для ребят примерка этих «практик» ежедневная работа, а для нас единовременная активность, они в этом разбираются лучше.
«комплексное виденье»
Плохо получается у ребят, либо слишком абстрактно либо слишком узко-«в лоб».
А даже когда у ребят выходит хороший продукт, его Потребители (Руководство), порой не в состоянии его потребить.
За «комплексным виденьем» лучше не к консультантам, а руководителей отправлять в бизнес-школу.
Но Консультанты нужны и очень в следующих ситуациях:
Добавлю ещё пару уточняющих моментов.
Момент №1
Если функционал новый
После того как новый бизнес-процесс спроектирован и наложен на текущий интерфейс Приложения, Заказчик отключается от данного процесса и включается в работу Системный Аналитик.
Системный аналитик формулирует перечень проблем: что надо добавить и изменить. На основе подготовленного документа он общается с Архитектором и Разработчиков как они будут решены и добавляет ответы на вопросы к сформулированным проблемам, переводит их в задачи.
Решения показываются Бизнес-аналитику, он их проверяет на соответствие целям и результатам бизнес-операций. Если технические ограничения не позволяют реализовать бизнес-процесс в заявленном виде, уже отталкиваясь от текущих возможностей Бизнес-аналитик готовит новый вариант выполнения бизнес-операции и согласовывает с Заказчиком.
На этом этапе согласования подключается Тестировщик и вместе с Системным Аналитиком готовит сценарии тестирования.
Документ, разработанный Системным аналитиком, и всё что готовится дальше Заказчику не показывается. Заказчик получает подтверждение Бизнес-аналитика, что Приложение будет обеспечивать новый вариант бизнес-процесса, Заказчик подтверждает, что мы можем начинать реализацию.
Если функционал не новый
Изменения в реализованный бизнес-процесс Бизнес-аналитик вносит через документ «Дополнение к ТЗ», который указывает какой раздел описания бизнес-процесса изменяется и на что.
И далее по цепочке, подключается Системный аналитик и анализирует новые требования к Приложению.
Момент №2
Наличие «картинок и кнопок» в ТЗ делает описание бизнес-процесса для Заказчика похожим на правду. Из абстрактного, описание превращается в конкретное.
Сравните
Создаёт в системе новое поручение через специальную экранную форму.
И
Нажимает на кнопку «Создать новое поручение»
на открывшейся форме «Нового поручения»
сотрудник ОККЭ заполняет поля …
Если Пользователь уже знает интерфейс системы, то для него такое описание выглядит ещё более правдивым.
Когда ТЗ содержит много абстракций и они ссылаются друг на друга, Пользователи теряют общее видение решения и отсюда «прилетают» ошибки в логике работы, которые хуже ошибок в коде. Ошибку в коде можно быстро поправить, а ошибку в реализованной логике может и не получится быстро устранить.
Корпоративное ПО создается для решения специфичной для данного бизнеса задачи, часто это решение является неповторимым. Для другой компании оно не подойдет, так как рабочий процесс у неё устроен по другому.
Заложенная в решение бизнес-логика толкает исходную информацию по производственной цепочке. Главная задача обеспечить работоспособность бизнес-процесса, а не Корпоративной ИС.
По этой причине описывать работу Корпоративной ИС лучше с точки зрения бизнес-процесса, а не функциональных возможностей системы.
Когда описываешь КИС с позиции рабочего процесса ТЗ начинает сильно быть похожим на руководство пользователя, охватывая работу разных типов пользователей в ней. Те участки, что не покрывались текущим решением отражались на схеме и в описании как выполняемые без КИС. Это служит целеуказателем куда дальше развивать ИТ-решение.
Полученный документ это:
В этом отличие внутри разработанного ПО от массового, универсальных продуктов, таких как Atlassian JIRA. Последние представляют собой набор кубиков, из которых создаешь нужное решение. Если тебе их не хватает ты можешь поискать другие на маркете или сделать свои. Для таких систем документацию стоит описывать с точки зрения функциональных возможностей кубика, что им можно делать и для чего использовать, и отражать изменения в работе функциональности.
В документации на КИС нужно отражать изменение бизнес-процесса и ИТ-решения чтобы обеспечить целостность первого.
В нашем случае описать изменения в функциональности технический писатель может, а вот отразить изменения в бизнес-процессе и сделать это по факту нет.
Причина первая – технический писатель не бизнес-аналитик и часто не владеет глубокими познаниями как в конкретном бизнес-процессе так и в их цепочке в целом. Скажу что это даже не его работа, не его задача.
Вторая причина – ему не дадут это сделать после, а не до. Система находится под большой нагрузкой, переваривает 60 миллиардов рублей в год, в день это 170 мил. рублей в день. В ней работает более 2000 пользователей. Простой системы – это финансовые потери и последующие «перегрузки» в работе компании, так как выпавший в работе день нужно будет нагонять. Есть понимание что “time to market” должен быть минимален на столько на сколько это возможно, но при условии, что риск будет сопоставим с получаемой выгодой. Если риск убытков высок, а выгода не покрывает их, то мы склоны сперва спроектировать новый бизнес процесс, посмотреть как мы будем работать на тестовой среде и только после этого ставить обновление на промышленную систему и проводить изменение в бизнес-процессах компании.
Взгляните на это с ещё одной точки зрения, что результат нашей работы это не готовая программа, а новое ИТ-решение включающее и программу и бизнес процесс.
Согласен с вами, в общем случае это лишнее. В текущем виде отражена особенность нашей внутренней процедуры работы с документами. У нас тоже был электронный документооборот. Вместо того, чтобы заменить бумажный он стал для него учетной системой, в которой отражается статус прохождения бумажного документа, а в конце прикрепляется скан.копия с «живыми» подписями заинтересованных и ответственных сторон. Поэтому лист согласования присутствует в шаблоне, на нем эти «живые» подписи затем собирались.
Мне кажется, вы смотрите на неё только с точки зрения Разработчика.
Основание для разработки – это для Аудита, чтобы связать то что сделано (на что были потрачены ресурсы) с бизнес-запросами (обоснованием этих затрат).
Тема разработки и бизнес-процесс предназначены для Бизнес-аналитика по направлению, чтобы внести данные в реестр ТЗ и в последующем осуществлять навигацию и поиск нужных ТЗ.
Постановка задачи, задачи и цель также предназначены для Бизнес-аналитика, чтобы быстро «считать» о чем ТЗ, что им реализовано.
Охваченные компоненты – это для Архитектора и Системного Аналитика, чтобы быстро «считать» есть ли интеграция с чем-то ещё или всё в рамках одной ИС.
Этапы внедрения – это для Заказчика и Руководителя ДИТ фиксирующие факт окончания работ и подтверждения, что решение принято Заказчиком.
Документ поделен на две части, то что вы видите это бизнесовая часть, а есть ещё техническая, которую бизнес-пользователи не видят и которую пишет системный аналитик для разработчиков. В ней он каждое «Нажал на кнопку, появилась форма для заполнения Такая-то» переводит в список задач что нужно сделать и что изменить. Бизнесовая часть не указывает есть ли эта кнопка, появляется ли в результате нажатия именно эта форма. Бизнесовая часть — это чистая фантазия Пользователя/Заказчика и Бизнес-аналитика на тему как будет выглядеть выполнение бизнес-операции в системе.
Бизнесовая часть также состоит из двух частей «Тела» и «Приложений».
В Приложения выносятся формы Отчетов, описание Алгоритмов и всё подобное.
За излишней детализацией незримо присутствует нотация IDEF0 (SADT), которая говорит, что у действия есть вход, выход, кто это действие выполняет, инструменты и управление. Мы дополняем вход указанием от кого кому, откуда куда, так как описание текстовое.
Сложилось впечатление, что вы так разводите два этапа работ, описание бизнес-процесса и проектирование программы.
В нашем случае мы сразу проектируем бизнес-процесс визуализируя его на системе. То что нам может не хватить технических возможностей, Бизнес-аналитика и Пользователя этим не заморачиваем, пусть рисуют концепт. Дальше в момент анализа и проектирования технических решений станет ясно, что можем, а что не можем и какую альтернативу будем предлагать Пользователю, чтобы обеспечить тот же результат выполнения бизнес-операции.
Проектирование бизнес-процесса на системе одновременно «заземляет» Бизнес-аналитика и Пользователя минимизируя разрыв между тем, что хочется и тем что есть сейчас.
Так решается проблема, что ребята могут придумать новый концепт, который в корне отличается от существующего, разработаны новые регламенты и подготовлено ИТ-решение, но им просто Страшно переходить на новую схему, так как никто в ней не умеет работать, полное виденье есть у Начальника и Проектировщика, но им страшно не меньше чем всем остальным. Страх нагоняет упоминавшийся выше контекст, что подразделение находится под существенной нагрузкой и они не готовы к возможным не предвиденным остановкам. Поэтому здесь работает стратегия эволюционных изменений в сторону нового концепта.
Ты делаешь хорошо на протяжении нескольких лет, но тут вдруг высокий начальник меняется.
Он приходит и говорит: «Ребята, всё что вы тут создавали несколько лет, это фигня. Мы это выбрасываем и теперь вместо этого будет вот это». И это сразу отбрасывает всех на несколько лет назад…
При этом:
— платят в рынке;
— скилл-ы у команды выросли;
Как итог — задачи мы решаем быстро и эффективно, но мотивации делать это ещё быстрее и лучше нет, так как завтра это могут вновь уничтожить.
Чем то это похоже с ситуацией когда пишешь текст (письмо, свой вариант...), накатал страницы на две-три и тут вырубают свет, а ты при этом не делал резервную копию…
Если этот человек в своём деле при этом эффективен и результативен, то он уже не Энтузиаст, это Герой.
Эффективность и результат указывают на то, что среда меняется.
Например, есть пруд.
Если его не чистить и не сделать систему отвода воды, вода будет стоять и он превратится в болото.
Если человек чистит пруд от тины и зарослей, а также сделал отвод воды, она стала проточной, сделал это по внутренней мотивации не на заказ, то для тех кто этим прудом пользуется (купается, ловит рыбу...) и «понимает», что это результат чьего-то труда, для них он Герой.
Данное вами определение Энтузиаста верно и именно в этом оно совпадает с определением Автора.
Результата нет, но внутреннее желание и, возможно, какая-то активность сделать что-то полезное для общества есть.
Эта статья на них не похожа, здесь есть оригинальный сюжет и новизна.
Взгляните на это как на личный поиск, попытку разобраться в предмете.
Через такой же путь прошла Биология в своё время (отсылка к Дарвину «Происхождение видов», но были и попытки до него).
И Астрономия — Н.Коперник, Д.Бруно…
Кстати о последнем, сейчас то что происходит по отношению к автору и его статье очень походит на историю с судом инквизиции.
Будто мы знаем в чем Истина-Правда, а автор статьи ошибается, поэтому мы его минусуем.
Автор знаком с историей (только за это уже заслуживает плюса) и оперирует определенными артефактами (Греческий Герой, Картожане, Рабы, Пленные...) накладывает их на линию «Труд/Работа» и пытается понять в чем Мотивация каждого из Артефактов трудится эффективно.
Результаты этого исследовательского труда оформлены в статью и ещё и иллюстрированы для облегчения восприятия (это повод для ещё одного плюса).
Понравилась. Делюсь с вами статьёй своего знакомого Дмитрия Тарасова.
«Почему в основе продуктивности лежит управление энергией, а не временем»
Я дополнил его статью своим развернутым комментарием про физический и ментальный тонус, что они также нужны, чтобы быть продуктивным.
Также Дмитрий выпустил своё приложение Хаос контроль для работы с задачами.
Если денег много, можно всю 1000 задач по 1000 рублей сделать, за этим прилетит ещё 1000 по 1000, из которых 500 будет переделать то, что сделали раньше, либо чтобы вернуть как было либо потому что надо по другому.
Но в целом ваш вариант вполне рабочий, посадили программиста со знанием предметной области в «песочницу» и там он с Заказчиком что-то лепит.
Если нужны какие-то сквозные изменения затрагивающие работу нескольких подразделений, ваш вариант потребует усложнений и изменения «архитектуры» системы, при этом в последующем ваш программист не может менять тот «кирпич», который у него отмечен, что им пользуется соседнее подразделение.
Для этого придется с ним договорится об изменениях в нём.
Когда денег в компании станет меньше, а привычка получать от ИТ всё что хочется останется, у вас начнет бэк-лог увеличиваться, а вот новых ресурсов вам не дадут, так как денег нет в компании.
Вы и придёте к описанной ситуации, что вы делаете что-то полезное для бизнеса, а вам говорят что этого мало и медленном, получите дизлайки от бизнеса.
Что что-то нужно менять.
А далее как в приведенном комментарии
https://habrahabr.ru/post/314448/#comment_9897288
Вы правы, мы столкнулись с торможением и пошли по пути который вы предложили.
Выглядел он в двух словах так:
Заместителю генерального директора некогда и неинтересно согласовывать доработку формочки за 100 000 рублей.
Если есть ТЭО и оно говорит, что её выгодно дорабатывать, ему этого достаточно.
То что выгода будет достигнута, проверит Внутренний Аудит.
Если не будет достигнута, Заказчика наказать не накажут, но проверят окупится ли хотя бы и возьмут на заметку.
Если развивать мысль, то ИТ нужно будет отправить и в продажи и в маркетинг и в логистику… во все бизнес-подразделения понимать как они работают и какие операции какой сложностью и трудоемкостью обладают.
Мне хочется уберечь Разработчиков от этих «душевных травм и драм» и отправлять в бизнес-подразделения Бизнес-аналитиков, чтобы они делили боль Заказчиков из бизнес-подразделений.
Не поспоришь, всё что отнимает чудовищное количество времени у сотрудников нужно изучать и думать можем ли мы эти затраты уменьшить.
И делать это не только из чувства сострадания бухгалтеру, но и потому что это выгодно.
Личное наблюдение.
Там где начинается саботаж новых продуктов, эти компании начинают проигрывать конкурентную борьбу. Вопрос в том на сколько хватит прочности у организации.
Там где в компаниях экспериментируют и пробуют что-то новое, случаются и инсайты и кратный рост эффективности, работать и интересно и платят хорошо, так как есть из чего платить.
Похоже на то, что программисты получают новую квалификацию «Бизнес-аналитиков» и для них задачи перестают быть «обезличенными», они понимают для кого и что они делают, удобно ли этим пользоваться и есть ли эффект.
Ваш посыл мне в целом понятен.
Добавил бы что «рыба гниёт с головы», но часто не в наших силах заменить Руководителя в подразделении.
В моем случае это сводилось к тому, что я начинал выбирать «вменяемых» внутренних Заказчиков, которым была нужна возможность. Работа с ними, со временем, начинает отрезвлять окружающую обстановку и подтягиваются другие адекватные заинтересованные лица.
Вы меня ничуть не задели и у нас не просто спрашивали сколько человек сокращаем, а пытались сокращать.
И если сотрудников не сокращали, то спрашивали куда ушла экономия.
В результате это стало сильным мотиватором для бизнеса начать использовать JIRA в своей работе, чтобы ответ на этот вопрос был прозрачен / оцифрован.
Если в компании никто не проверяет достигнут ли был результат, то вы правы люди только научаться манипулировать цифрами и уметь с их помощью обосновывать свои задачи.
Это уже полшага вперёд.
Здесь есть два варианта, что будет дальше. Мы использовали оба.
Первый — Руководство перестало давать ресурсы подразделениям на прямую. То есть для достижения увеличившихся показателей вы не можете получить ещё людей, ищите возможность повысить внутреннюю эффективность.
Например, нужно сделать уже не 10 продаж, а 20. Простой вариант, нанять ещё продавцов, а сложный это работать с воронкой продаж, конверсией и что-то оптимизировать в своей текущей работе, чтобы это время на работу с воронкой продаж и конверсией появилось.
Второй — у нас Внутренний Аудит получил новое поле для своей работы. Замерять «до» и «после».
Где-то справлялись хорошо и без него, где-то он учил руководителей считать и замерять.
Она будет скорее эмоциональная, чем экономическая.
Вам будут благодарны за то, что вы сделали, но вот сколько выгоды в рублях и есть ли она это неизвестно.
При этом будет то что можно точно замерить, это сколько времени было затрачено на их реализацию, и сколько вы должны получить в кассе предприятия.
Затраты, которые будут профинансированы из прибыли компании.
Представьте, что и Продавцы в компании будут работать также. Не оценивать привлекательность клиентов, а продавать каждому желающему по одной ручке за 1 рубль, затрачивая на это по 2-3 дня своего рабочего времени на сделку. Долго такой бизнес не протянет.
Это уже экономия для компании 1,5 рублей.
, но
Если после составления ТЭО задачу становится не выгодно делать, то ее уже можно не делать.
Цель ТЭО — остановить поток таких мелких, которых делать нельзя, задач так как польза для компании от них либо минимальна либо вообще никакой, если они даже затрат на составление ТЭО не окупают. И сосредоточить имеющиеся ресурсы на тех задачах, которые будут приносить максимальную отдачу для Компании и Клиентов.
Пример.
Задача №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-а.
Если этого не делать, мы чаще будем «жечь» дефицитные и дорогостоящие ресурсы разработки в пустую, чем создавать что-то реально ценное.
Пришел работать в компанию уже после того, как ребята съездили в командировку, CRM-система была закуплена и развернута, начат процесс по её доработке/развитию.
У нас был и электронный и бумажный архив документации на систему. Последний ведется по той причине, что компания каждый год проходит проверку Генеральной Прокуратурой и Счетной Палатой на предмет целевого расходования средств, так как основной акционер компании Государство.
Их интересует:
— кто авторизовал расходование средств на ИТ-систему,
— на что они пошли и зачем это было нужно,
— кто делал / кто получил деньги,
— кто осуществлял приемку.
в 2014 году начали экспериментировать с Электронно-Цифровой Подписью для взаимодействия внутри и с Партнерами, чтобы отказаться от бумажного документооборота в пользу юридически значимого электронного.
Погуглил.
Так как у меня остались смутные воспоминания, со времен изучения SADT, что в Америке в 70-е годы документация на ИТ-системы доходила до нескольких тон, если это касалось систем масштаба страны.
Structured Analysis and Deign Technique появилась в 1969-1973 году.
Упомянутые здесь в комментариях GIT и SVN появились в 2000-е.
CVS первый выпуск 1990.
Freddie Mac появилась в 1970 году.
в 2006 году оборот компании 44 млрд. долларов.
Активы в 2015 году 1,946 трлн. долларов.
Fannie Mae появилась в 1938 году.
Активы в 2014 году 3,2 трлн. долларов.
Даты создания компаний, масштаб бизнеса, дата появления SADT и даты появления систем управления версиями указывают на то, что у каждой ТЗ на ERP-систему могло быть больше чем в 3 шкафа.
Тоже написал статью про наш «legacy» проект на днях.
Так как был руководителем проектов, то начали раскручивать клубок через технические задания. Приводя в порядок их и те куски, что им соответствовали внутри.
В нашем случае Проблема выглядела так, когда мы делали что-то одно, у нас отваливалось в нескольких других местах. У Заказчика сложилось впечатление что «Нормально» сделать с первого раза мы ничего не можем. Причина её заключалась «в сплошном коде», в котором было непонятно где заканчивается одна фича и начинается новая, и задача была разметить его на «функциональные области».
UPD. «Сплошной код» это была не вина Разработчиков, так как система изначально была коробочной и для настройки, а не для того чтобы на её основе разрабатывать отраслевое ИТ-решение.
Прошу простить мой технический русский, не разработчик, это мой обывательский взгляд РП-БА на ИТ-систему.