Техническое задание

Техническое задание:

1. Размеры платы: 9096 мм (3.5503.775").

2. Соответствие стандарту PC/104 по расположению отверстий межплатных стоек.

3. Толщина платы: 1.6 мм.

4. Подключение аккумуляторов: 2S2P.

5. Аккумуляторы: типоразмер 18650, напряжение - 3.7 вольт.

6. Расположение всех элементов на одной стороне платы (для того, чтобы ставить плату на сборку).

7. Использование DS18S20Z+ (SO-8) для измерения температуры аккумуляторов (2 шт).
   Использование DS18S20+PAR (TO-92) для измерения температуры нагревательного элемента (1 шт).

8. Разъемы Molex Picoblade (обозначение SP на плате) для подключения солнечных панелей (6 шт).

9. Разъемы PBD-52 (обозначение H на плате) для соединения всех плат в один стек (2 шт).

10. Преобразователь 7.4-5 и 7.4-12, если для какого-то компонента нужно будет напряжение 3,3 вольта,

11. Рабочая температура: -40...+85 C.

В комментариях жду ваши вопросы, пожелания и предложения.

В основе многих наших действий или бездействий лежат неразрешенные конфликты.

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

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

Элияху Голдрат, создатель Теории Ограничений, говорил, что конфликтов на самом не существует и мир живет в гармонии. Просто никто не пытается разобраться в причинах конфликтной ситуации.

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

Многие практики Теории Ограничений утверждают, что Грозовая туча работает.

Давайте проверим и попробуем применить разработанный Голдратом алгоритм к нескольким типичным конфликтам из области ИТ. Посмотрим, как это может нам помочь.

Конфликт: Подрядчик не начинает разработку до тех пор, пока не составит полное ТЗ

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

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

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

Как быть? Ведь заказчик хочет начать работу прямо сейчас и готов бросить всё, если Вы не начнете, и уйти к другому исполнителю. Конечно, ему нет никакого смысла ждать пока подрядчик напишет ТЗ (если вообще напишет). Это потеря его времени и, на самом деле, упущенной выгоды.

Какое же решение принять подрядчику?

Уже сейчас, из самой формулировки конфликта очевидно, что действие Начать работу только после составления ТЗ вызвано отсутствием гарантии получения денег от заказчика.

Т.е. причиной действия Начать работу только после составления ТЗ является необходимость Обеспечить гарантию получения денег.

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

Очевидно, что он не хочет затягивать создание своего продукта. Он хочет получить его как можно быстрее и считает, что составление ТЗ только всё затянет.

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

Но при это оба, и заказчик и подрядчик хотят создать это продукт. Т.е. у них общая цель Создать продукт

Каждому пункту конфликта принято давать буквенное название: A, B, C, D, D.

Итак, конфликт полностью сформулирован. Это так называемая диаграмма Грозовая туча.

Проведём быструю проверку. Условие C должно конфликтовать с действием D, а условие B должно конфликтовать с действием D. Всё верно, они конфликтуют, значит формулировка конфликта составлена правильно.

Для того, чтобы разогнать эту грозовую тучу необходимо разобраться в причинах конфликта. Пропишем причины (предпосылки), почему действия D и D необходимы для обеспечения условий B и C.

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

Было: Быстрее создать продукт. Обратная формулировка: Старт разработки бесконечно затягивается.

Было: Обеспечить гарантию получения денег. Обратная: Деньги за сделанную работу не оплачивают

B-D (при каких условиях старт разработки бесконечно затягивается?):

- Составление ТЗ занимает много времени

- Согласование ТЗ занимает еще больше времени в разы больше. Это огромные простои

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

- ТЗ часто используют в качестве давления на заказчика и есть риск не получить продукт, который я хочу

- После получения денег подрядчик часто исчезает бросив продукт недоделанным. По сути, это просто выброс денег в мусор

C-D (причины, почему деньги за сделанную работу не выплачиваются):

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

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

- Обычно разработка сильно затягивается из-за все новых и новых требований заказчика. Он никак не может остановиться

- Объем работ должен быть ограничен, чтобы заказ окупился

Как не трудно заметить, конфликт очень серьезный. Как найти решение, которое полностью его устраняет?

Э.Голдрат говорит, что суть конфликта скрывается в деталях. Его причиной может быть либо неправильная (ложная) предпосылка, либо непонимание предпосылок, на которых основывает своё видение противоположная сторона.

Можно придумать такое решение, которое либо вскрывает неверную предпосылку, либо удовлетворяет сразу всем предпосылкам всех сторон конфликта (причем полностью, а не частично).

Давайте подумаем За предпосылки сомневаться не приходится это то, что в действительности часто происходит в реальности. Значит надо придумывать что-то иное.

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

Каким образом можно совместить ограниченный объем работ и быстрый старт разработки? Очевидно, что чем меньше объем работы, тем точнее его предсказать и тем быстрее начать и проще сделать.

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

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

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

Давайте посмотрим, что случится с предпосылками конфликта, если применить найденное решение.

Опасение заказчика

- Составление ТЗ занимает много времени

На короткую итерацию ТЗ составить быстро, а то и вовсе можно обойтись без него заменив макетами экранов.

- Согласование ТЗ занимает еще больше времени в разы больше. Это огромные простои

На небольшой объем и согласование-то не особо требуется, т.к. согласующие очень быстро могут со всем ознакомиться и дать свой ок.

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

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

- ТЗ часто используют в качестве давления на заказчика и есть риск не получить продукт, который я хочу

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

- После получения денег подрядчик часто исчезает, бросив продукт недоделанным. По сути, это просто выброс денег в мусор

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

Бонус для заказчика теперь можно смело нанимать разработчиков давая им небольшой объем работ для проверки и рискуя только небольшой суммой.

Опасения подрядчика

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

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

- Подрядчик вынужден оплачивать зарплату разработчикам, чтобы они доделывали продукт. Это выводит проект в минус.

При оплате за небольшие итерации деньги будут на счете подрядчика не дожидаясь полного завершения проекта. Это в разы выгоднее.

- Обычно разработка сильно затягивается из-за все новых и новых требований заказчика. Он никак не может остановиться

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

- Объем работ должен быть ограничен, чтобы заказ окупился

Он однозначно ограничен.

Да! Решение полностью исключает все опасения! Грозовая туча работает!

Внесём дополнительные осложнения для подрядчика

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

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

Как закрыть опасения? Как сделать так, чтобы оплата осуществлялась по небольшим итерациям в проекте, котором УЖЕ чётко прописано, что оплата только в конце?

Давайте составим грозовую тучу и посмотрим на неё внимательно.

Причиной возникновения конфликта часто становятся неверные (ложные) предпосылки. Для их определения Голдрат в своих выступлениях (можно найти на Youtube) рекомендует задавать предельно простой вопрос: Really?! (Да ну?!)

Действительно ли внутреннему аудиту большой компании нужно показывать работающий продукт? Точно?! Вы действительно уверены, что нужно доводить готовый продукт до приёмо-сдаточных испытаний? Вы уверены?!

По умолчанию да, но что, если пойти и объяснить сотрудникам внутреннего аудита чем хорош подход с короткими итерациями?

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

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

Конечно, есть шанс, что ничего не случится, но тогда ситуация не будет отличаться от текущей и подрядчик ничего не теряет. Ну а что, если внутренний аудит пойдет навстречу?..

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

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

Но это отдельная история.

Целью статьи было рассказать Вам о том, что с помощью Грозовой тучи можно найти очень интересные, часто прорывные решения.

Вероятно, изложенный в статье способ применения диаграммы Грозовая туча покажется Вам полезным. Было бы очень интересно увидеть Ваши примеры её использования.

На Ваши комментарии автор с удовольствием ответит и примет к сведению Ваши замечания.

P.S. История, рассказанная одним из рецензентов после прочтения статьи.

Просишь пример? Пожалуйста.

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

В Чехии он не нашел подходящих вариантов. Договор с фирмами его не устраивал как раз по причине того, что надо было разрабатывать ТЗ и расписывать работы на весь договор, платить сразу приличные деньги, а он четко даже не представлял, что ему, собственно, нужно.

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

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

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

Аналитик, проанализируй мне эту задачу - говорит бизнес-заказчик. Что он имеет в виду? Анализ - это всего лишь метод исследования, характеризующийся выделением и изучением отдельных частей объектов исследования (по википедии), но бизнес в своих словах подразумевает нечто большее, чем просто анализ.

Что делает ИТ-аналитик и в чем ценность его работы для бизнеса? Пробуем разобраться.

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

Понятия потребность и требование

В анализе и проектировании аналитик работает с двумя областями. Область потребностей = нужд (needs) и область решений (solution).

Закрыть одну потребность можно разными способами. Каждый способ имеет разные атрибуты качества. Поесть в ресторане быстрее и вкуснее, но купить продукты в магазине, приготовить и съесть что-нибудь дома дешевле.

Бизнес обращается к нам с какой-то проблемой, болью, которую он не знает как решить и наша задача - показать ему что делать.

Задача аналитика в поиске и выборе наиболее подходящего для заказчика способа решения (solution) его боли и проблемы.

Выявление потребностей и целеполагание

Пациент приходит к доктору и требует Выпишите мне аспирин, срочно!!!.

Требование = Выписать аспирин. Что делает доктор в данном случае? Плохой доктор даст аспирин. Хороший доктор будет выявлять причины проблемы и лечить их.

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

Требование лежит в области решения (solution). Поесть в ресторане, Приготовь еду - это требования.

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

Поэтому аналитик выявляет потребности и проектирует решение (требования к решению).

В разное время разные бизнесы стремятся к оптимизации разных атрибутов качества своих систем и процессов.

1. Обеспечить функциональность

2. Качественную работу

3. Скорость/Производительность

4. Безопасность

5. Низкие издержки

6. И т.п.

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

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

Выявление контекста и ограничений

Разумеется заказчик находится в какой-то ситуации и он ограничен принятыми ранее решениями (decision).

Разгрузить грузовик - это сложно? Неясно, так как неясен контекст.

К примеру, Разгрузи грузовик в минус 40, на дне озера и Разгрузи грузовик в плюс 25, на асфальте выглядят как совершенно разные задачи.

Для проектирования модели нужно разобраться в контексте того, как полученное решение (solution) будет использоваться, в каком процессе и для чего. Какая ситуация у заказчика.

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

Перед проектированием будущего изменения часто нужно выявить желаемые сроки внедрения. Возможны разные варианты:

1. Сделать к черной пятнице,

2. Сделать, потому что каждый день мы что то теряем,

3. Сделать, иначе с какого-то момента мы будем каждый день что-то терять.

Таким образом выявляются ожидания/ограничения по срокам.

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

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

В итоге, складывается понимание ограничений на проектный треугольник (стоимость/сроки/качество).

Кроме того, область решений (solution) ограничена еще:

1. Ограничениями по ресурсам

2. Требованиями удобства пользователей

3. Решениями по существующему ИТ-ландшафту и уровню ИТ сервиса

4. Выбором подрядчиков и правилами привлечения новых

5. Правилами работы с подрядчиками

6. Требованиями безопасности и распространения информации

7. Требованиями регуляторов

8. И т.д.

Не зная ограничения, нельзя спроектировать решение с их учетом.

В случае слишком жестких ограничений решения может и не найтись. Тогда ограничения заменяются функциями штрафа и аналитик ищет наименее болезненное решение.

Проектирование решения

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

Моделей системы может быть несколько (и довольно много), но типовые это

1. Функциональная модель, отвечающая на вопрос как это работает, функционирует, обеспечивает функцию.

2. Конструктивная модель, отвечающая на вопрос как это сконструировано, из каких частей состоит.

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

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

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

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

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

ИТ аналитику в поиске помогают

• Знание того, как ИТ решают задачи по улучшению процессов,

• Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

• Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

• Знание предметной области,

• Знание процессного управления и процессов управления изменениями,

• Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

• Ну и разумеется, эксперты, партнеры по интеграции, смежники, вендоры ИТ решений и разработчики.

• Знание того, как ИТ решают задачи по улучшению процессов,

• Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

• Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

• Знание предметной области,

• Знание процессного управления и процессов управления изменениями,

• Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

• Ну и разумеется, эксперты, партнеры по интеграции, смежники, вендоры ИТ решений и разработчики.

• Знание того, как ИТ решают задачи по улучшению процессов,

• Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

• Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

• Знание предметной области,

• Знание процессного управления и процессов управления изменениями,

• Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

• Ну и разумеется, эксперты, партнеры по интеграции, смежники, вендоры ИТ решений и разработчики.

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

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

Дайте мне аспирин А это вылечит вашу боль?(неизвестно, если причина боли не диагностирована)

Внедрение решения

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

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

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

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

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

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

Резюме

Работа аналитика это превращение проблем в задачи, при котором характерны этапы:

1. Выявление потребностей и целеполагание,

2. Выявление контекста и ограничений,

3. Проектирование решения,

4. Внедрение решения.

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

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

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

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

P.S. Спасибо участникам КиФБ за отзывы и корректировки к статье