Один раз мне задали вопрос: чем бизнес‑аналитик отличается от секретаря? Казалось бы, разработке ПО в России уже больше 2х десятков лет, но роль бизнес‑аналитика до сих пор вызывает вопросы.
В принципе, вместо секретаря можно добавить любую другую профессию и спросить: а чем БА отличается от бухгалтера, от юриста или технического писателя?
Разработка любого продукта или ИТ проекта начинается с формирования команды. Как это происходит: допустим, Заказчик у нас сразу есть. Кто еще нужен в команде?
Обычно сразу называется Разработчик. И вот заказчик говорит, что он расскажет разработчикам, что нужно сделать и сейчас они быстренько сделают продукт. Ну, допустим, верим.
Нужен Дизайнер. Чтобы были красивые и удобные интерфейсы
Нужен Тестировщик. Кто‑то же должен найти баги, мы знаем, что кода без багов не бывает.
Народу у нас в команде уже много, очевидно нужен Руководитель проекта
А еще часто кто‑то произносит: нам нужен Бизнес‑аналитик! Только что же он будет делать — многие не знают. Кто этот человек? Что он делает?
Допустим нам нужен в команду аналитик, а какой? Бизнес аналитик, системный или фул стек? А чем вообще отличается БА и СА?
Давайте разбираться
Под словами Бизнес‑аналитик чаще всего подразумеваются минимум 2 разные профессии:
1-я — это сотрудник бизнес‑ подразделения какой‑то компании, который действительно занимается анализом бизнеса компании. Графики, отчетность, прогнозы развития той или иной услуги, выручки, окупаемости и т. д.
2-я — это сотрудник ИТ подразделения или ИТ компании. Это тот БА, который является частью команды разработки какого‑либо программного обеспечения. Именно про этого БА дальше и пойдет речь.
Бизнес‑аналитик — это человек, основной задачей которого является перевод языка бизнес‑заказчика на язык разработчиков. Очень утрированное и простое определение. Тем не менее это одна из наиболее важных задач БА.
А не может ли Заказчик сразу ставить задачу разработке так, чтобы они понимали?
Нет не может
Бизнес заказчик или Product Owner часто (не всегда, но часто) описывает некий образ результата, который он хочет получить. Например: Реализовать возможность работать с комментариями в задаче. Создавать, удалять, редактировать. И может добавить: ну как везде. Какие вам еще требования нужны?
В лучшем случае разработчик замучает заказчика вопросами, которых будет очень много.
в каком формате показывать дату и время комментария?а ФИО пользователяа аватарку показывать?а сортировать в порядке убывания или возрастания?а кто должен иметь права на редактирование?а если, а если, а если?
В худшем случае разработчик сделает как сам понял/придумал/видел где-то.
Так вот, БА — это тот человек, который опишет (и это очень важно. Не расскажет, не споет, не станцует и не запишет голосовое. Он напишет!) очень подробно, что же мы хотим получить на выходе. Это и будут наши требования — которые разработка возьмет на вход.
Требования
Требования можно разделить на бизнес требования и системные.
Бизнес требования — это требования, которые важны с точки зрения бизнеса, т. е. заказчика. Это могут быть требования к интерфейсу: форматы отображения данных, набор функций. Это по сути то, что определяет, как должен выглядеть продукт и что должен делать.
Системные требования — это описание того, как разработка должна реализовать бизнес‑требования. Описания методов, таблиц в БД, полей, API и т. д.
Аналитик, который пишет бизнес требования — бизнес аналитик. А аналитик, который пишет системные требования — системный аналитик.
Если очень упростить, то БА — это человек который пишет человеческим, русским языком. Он описывает ЧТО нужно сделать. А СА — описывает КАК разработка должна это сделать. т. е. пишет системные требования на уровне таблиц БД, задач на бек, фронт и т. д.
Кажется, что все просто. Но, ха‑ха, дьявол в деталях. Бизнес‑требованиями могут быть и требования к интеграциям. Например, интеграция Биллинга и CRM. Если сутью доработки и основной бизнес‑ценностью является не отображение в интерфейсе возможности оплатить счет или подключить услугу. А, например, обогащение каких‑то данных которые хранятся в базе, то требования к этим данным вполне тоже могут быть бизнес‑требованиями.
Сложности всегда начинаются тогда, когда мы пытаемся формально разделить БА и СА. И здесь часто возникает фул стек аналитик — который сразу и БА и СА. На самом деле редко можно встретить реально фул стек аналитика, все‑таки это немного разная специфика и разные скилы, опыт. СА — это уже немного разработчик. А БА — это немного РО. А фул стек это немного и то и другое. Но чаще это проще, чем пытаться разделить требования по критериям.
Фиксация и управление требованиями
Все требования бизнес аналитик обязательно фиксирует. Это могут быть документы совершенно разного уровня: ТЗ, ЧТЗ, БФТ, Спецификация, Use case, user story, постановка. Это могут быть документы в word по ГОСТу или странички в Базе знаний. Но требования должны быть зафиксированы.
Требования должны быть записаны, пронумерованы (желательно), проверсионированы, трассированы (т. е. связаны между собой).
БА декомпозирует требования: разбивает на более мелкие кусочки, чтобы разработке было проще их кодить.
И важный шаг при работе с любыми требованиями — их согласовать! Это отдельный скил для БА, уметь согласовать документ с разными заказчиками, особенно если у них вообще разные цели и задачи на систему.
Я всегда задаю вопрос на собеседованиях: если у вас 3 заказчика и они вам говорят противоположные требования к системе, что вы будете делать? По ответам всегда понятно, имеет ли кандидат реальный опыт работы БА.
Что еще важного делает БА?
Конечно же, проектирует бизнес‑процессы! Существует множество нотаций, у каждого БА есть свои любимые. Я считаю, что хороший бизнес процесс — это тот, который понятен и бизнес-заказчику, и разработчику без специальной подготовки.
Бизнес‑процесс может описывать как поведение одного пользователя в одной системе (например, работу с комментариями в задаче) или длинный сквозной бизнес — процесс через много систем (например, вы платите в личном кабинете за интернет и через 5 минут вам его разблокируют. Здесь будет порядка 10 систем участников и важно доработать каждую систему так, чтобы в итоге этот бизнес‑процесс заработал).
Ну вот, допустим, наш БА написал требования, оформил их в ТЗ или постановку. И все? Сел отдыхать? Плохой БА — возможно, но про таких и говорить не стоит. Мне очень нравится известная фраза: претензий к пуговицам нет, но костюмчик не сидит.
Бизнес- аналитик - это тот человек, который отвечает за то, чтобы костюмчик сидел
БА участвует в грумингах и обсуждениях с разработкой. Когда пишешь требования очень важно понимать, что и как можно реализовать, а что реализовывать будет очень долго или дорого. Бизнес‑аналитик должен убедиться, что разработка поняла требования правильно. Практика показывает, что любую даже очень однозначную фразу можно трактовать по‑разному. Важно вместе все прочитать, проговорить и зафиксировать так, чтобы точно было понятно всем.
БА участвует в приемке функционала и проводит его проверку. Аналитик обязательно проверяет в целом, получилось так как задумывалось? Может что‑то было спроектировано неудобно? Что‑то забыли? БА точно знает, как пользователь будет с этим работать, сможет ли?
Так как БА знает, что для пользователя важно, он еще проверит документацию для пользователя. Действительно ли функционал описан полно? Сделаны ли нужные акценты?
БА может помогать РО проводить демонстрации продукта, отвечать на вопросы пользователей.
На моем продукте БА являются еще и входной точкой со стороны 3 линии тех поддержки. Все в обращения, на которые не может ответить 1 и 2 линии, попадают к бизнес‑аналитикам продуктов. Если есть подозрение на дефект — мы передаем его в QA. Если пользователь предлагает какой‑то новый функционал, мы подсказываем, есть ли такое в беклоге развития продукта и если нет, то идем к РО с вопросом.
Часто есть ощущение, что БА только и делает, что со всеми разговаривает.
В принципе так и есть. А требования пишет в свободное от работы время в тишине рано утром или в выходные.
С кем же БА говорит?
С заказчиком — это первый шаг, вытащить, что же нужно сделать. И согласовать со всеми.
С дизайнером — проектирование интерфейсов никогда не может идти в отрыве от требований.
С разработкой — убедится, что разработка понимает, что нужно сделать.
С тестированием — помочь определить баг/не баг.
С тех писателям — помочь написать документацию.
С поддержкой — помочь ответить на вопросы пользователей.
С пользователями ‑рассказать о продукте, провести демо.
Ключевой навык Бизнес‑аналитика — умение найти общий язык с разными людьми. Чтобы в итоге костюмчик вашего продукта хорошо сидел.
Комментарии (15)
FabrLik
24.09.2024 18:53+2Спасибо за статью, прочитал с удовольствием!
Однако попробую кое-что дополнить в меру возможностей.
В ООП-разработке есть такое понятие "божественный класс".
Класс, который делает все и сразу.
В вашем описании БА выглядит, почему-то, как "божественный класс".
Обычно это происходит несколько иначе.
Делить СА и БА не имеет смысла, так как в крупной системе эти элементы будут плотно переплетены.
Ну либо вы раздуете штат в 2 раза и увеличите плечо согласований.
С учетом, что IT сотрудник - это дорого, то "дуть штат" заказчики не любят.
Например:
Заказчику требуется какая-то бизнес фича,
ее потребуется перевести с языка заказчика на язык разработчика.
Но прежде чем ее переводить - нужно оценить ее исполнимость, иначе есть риск того, что БА подпишется под неисполнимое в рамках бюджета задание.
Эта ошибка, кстати, встречается часто.
Более того, у каждого задания есть несколько вариантов исполнения, а значит требуется определить граничные условия.
Вот и получается, что БА должен быть немного разработчик, чтоб понимать, как это можно сделать " в теории", чтоб задать правильные вопросы.
Как это будет "на практике" - финально решит разработчик или тим лид исходя, как раз, из граничных условий.
Если же БА попробует сам спрогнозировать финальное решение на уровне кода и далее будет требовать исполнения "именно так",
то скорее всего это приведет к низкому качеству кода и сложности его поддержки.
Разработчик в 99,9% случаев напишет более оптимальное решение и выберет паттерн, который лучше соответствует задаче.
Далее потребуется зафиксировать User Flow.
И тут БА аналогично потребуется лишь на входе, так как далее задачу возьмет себе Тестировщик и Дизайнер.
Задача БА на этом этапе отрисовать каркас переходов и не более.
Как их лучше расположить и какие цвета выбрать - скажет дизайнер.
Как сделать так, чтоб никто не нажал лишнего - тестировщик.
Следом потребуется хоть как-то оценить вопрос железа.
Где будет развернуто ПО и как именно, какие есть условия по безопасности и т.п.
И опять же БА нужно задать правильные вопросы.
Однако задачей будет заниматься DevSecOps и это правильно.
Вот и получается, что БА подключается только в самом начале,
на этапе "согласования и запуска", а далее вопроса более не касается.
А если касается - значит плохо расписана спецификация и требуется уточнение.
Потому и знать БА приходится очень и очень много, но без глубины.
БА выступает в роли справочника, который сможет направить заказчика в нужное русло.
Как итог БА потребуются:
1) Хотя бы общие принципы передачи информации по сети (модель OSI).
2) Хотя бы базовое понимание разработки и принцип работы с фреймворками.
3) Хотя бы базовое понимание верстки сайтов (HTML+CSS+JS).
4) Хотя бы базовое понимание разных видов API (REST обязательно).
5) Хотя бы базовое понимание того, как ПО деплоится на сервер.
6) Хотя бы базовое понимание того, какая будет скорость ответов при том или ином решении (обязательно понимать разницу между ответами 200,300,400,500),
а самое главное почему ответ пользователям Москвы придет быстрее, чем пользователям Владивостока.
7) Хотя бы базовое понимание работы с БД.
Многие заказчики считают Excel базой данных и будут не понимать, почему нельзя использовать формулу из excel.
8) Иметь громадный уровень переговорных навыков, потому что потребуется много общаться со всеми подряд ради общей цели :)
А вот бегать и следить за правильностью исполнения - это уже к тех лиду, тим лиду, РМ-у и т.п.
У кого как принято, так сказать.
Но точно не к БА.
Недавно, кстати, комментировал схожую статью,
только она была написана от лица тестировщиков:
https://habr.com/ru/companies/samolet/articles/841906/
Предполагаю, что некоторые мои мысли оттуда будут полезны и здесь.
Цитаты:"Попробую расписать процесс, как его вижу я со своей колокольни.
Прошу сразу камнями не закидывать, так сказать мнение автора может не совпасть с вашим.
И надеюсь, что мое видение будет вам полезно в работе.По правильному, аналитик перед разработкой создает спецификацию того, что требуется создать.
Он создает это не просто так, а для того, чтоб разработчик мог "не думать" и делать то, что написано.
Сказано 4 ножки у табурета и высота в 2 бутылки 0.5 Кока-колы - делаем 4 ножки и высота в 2 бутылки.
Не сошлось - вопрос к спецификации.Причем делает он ее не абы как, а подробно, детально прописывая все, что потребуется знать разработчику и РМ."
"Следом идет роль РМ, который по сути должен получить подтверждение от Заказчика, что это действительно тот стул, который имел ввиду заказчик.
"От нас точно ждут табурет? Не стул, не кресло, не скамью? Табурет?" - должен спрашивать РМ у заказчика.
Мнения разошлись - спецификация уходит обратно к аналитику.
Мнения сошлись - информация идет на уровень ниже.""Далее начинается уровень Разработчика."
"После этого действительно наступает уровень Тестировщика."
Надеюсь, что комментарий был для вас полезен и поможет дополнить, при необходимости, статью :)
ITatianaEgorova Автор
24.09.2024 18:53Спасибо за ссылку, всегда очень интересно, как работу аналитика представляют себе другие эксперты. Но с вами я не согласна, БА не требуется (в общем случае) понимание верстки сайтов (HTML+CSS+JS) если он работает над мобилкой. И полный перечень вашего списка любому БА не нужен.
Если БА не работает с интеграциями, имеет права не знать REST. А если понадобится - узнает и научится на верхнем уровне.
БА - точно не технарь, он на стыке. Поэтому и продуктовую часть знает (не как РО), и технологию (но не как разработчик). Скажу откровенно - я не знаю, почему формулы excel нельзя использовать в БД. Но я на 200% знаю, что я могу пойти к разработчику, узнать почему и смогу пойти и рассказать это Заказчику так, что он поймет )
AATs
24.09.2024 18:53Грамотное описание задач БА. Встретишь не часто. Если коротко, то БА - это внутренний заказчик для команды разработки, который в процессе разработки должен осуществлять авторский надзор на всех этапах и помнить, что программисты народ специфический: документацию не читает, а делает так, как сам понимает. Т. е. ещё одна задача для БА: "бить по рукам программисту", чтобы делал то, что написано в проектной документации. Более подробно можно почитать в 2-х томнике А. А. Цветков. "Теория и практика бизнес-анализа в ИТ". - изд-во "Директ-Медиа". Москва-Берлин.
Lis777
24.09.2024 18:53"бить по рукам программисту" - это я люблю. И тыкать в ненужные ему бумажки. Значит я правильно выбрала новую профессию))
ITatianaEgorova Автор
24.09.2024 18:53Будьте аккуратны. Разработчик лучший помощник аналитика, друг и советчик. И приемщик вашей работы. С ним нужно дружить, любить его и ценить.
Иногда хочется конечно бить и даже убить, когда написанное ТЗ игнорируется полностью, а разработчик делает "как ему подсказывает здравая логика". Здесь всегда можно найти момент личного/профессионального роста: а может мое ТЗ никому не понятно? а может нужно было провести грумминг? а может нужно было рассказать что мы вообще делаем и зачем?
Мы на одной работе писали СЭД с нуля. Делали продукт почти 2 года. Через 2 года выяснили (как обычно случайно), что команда разработки не понимает, что такое Входящие, Исходящие, и вообще для чего нужна СЭД. Это был провал команды БА, до сих пор его помню (
Lis777
24.09.2024 18:53Получается хороший БА должен быть еще немного юристом, что бы объяснить важность СЭД для заказчика? Некоторые штрафы могут быть существенны - особенно в государственных, муниципальных закупках, где СЭД применяется по закону. А прослеживаемы товары? Документы по их обороту проходят только через ЭДО, в том, числе и по части оборудования, на котором разработчики работают (Мониторы и проекторы зарубежного производства). Получается разработчики совсем не боятся кнута (штрафов)? Правильно это же не им прилетит, а Заказчику. Был случай в централизованной бухгалтерии истекли ЭЦП у нескольких учреждений в срок сдачи отчетов, а системный администратор не изготавливает новые ЭЦП - нет настроения... По-хорошему человек 2 недели не понимал. Тогда мы (ответственные за представление отчетности) собрались и пошли к нему. Сказали за непредоставление отчета - штраф 200руб. за каждого физика, их около 200. Штраф получается 40 000. Платить будешь сам. Тогда это были существенные деньги. И хоть по закону с него их вряд ли можно было взыскать, но ему хватило суток что-бы выпустить все новые эцп. А в целом у нас были хорошие отношения - просто сис. админы и правда не всегда понимают почему мы такие злые.
OlegZH
Попытка, конечно, интересная, но и, как всегда, слишком короткая. В надежде на быстрый результат? Это что ж, умение важное такое — быстро что-то проговорить, и думать, что дело сделано. "Грумминг" провели? Галочку поставили? Молодцы!
А, теперь, ближе к делу.
Как ни крути, а дело в том, что да, аналитики нужны. Которые возьмут от заказчика то, что тем нужно, и дадут разработчикам то, что тем нужно. Можно ли обойтись бес посредников? Наверное, да. Но для этого должен быть готов универсальный продукт, где заказчик сам себе рисует требования. Но это уже ближе к ChatGPT, не так ли? Возможно, к этому дело и идёт. Это, ведь, ещё Дональд Кнут говорил о литературном программировании, когда можно на человеческом языке всё описать и получить на выходе готовую систему. Тогда и программисты-то не нужны: законодатели сели бы, прописал бы все правила бухгалтерского учёта, этиправила пропустили бы через аналог ChatGPT, получили бы некое СПО и, потом, установили бы это ПО на все компьютеры страны. Не так ли? Вот это, точно, была бы сказка!
Спускаемся на уровень ниже.
Кто такой системный аналитик? Это человек, который знает системы. Он владеет системной методологией. Он знает, что у этой системы может быть вот такой куцый набор функций, а вот у той — просто широчайший. Соответственно, у разных систем будет и разный состав компонентов. физическая реализация этих систем также будет различной. Но можно предложить некую общую архитектуру, куда удастся уложить и простую систему, и сложную систему. Тогда системный аналитик сможет настоять на том, чтобы перед обслуживанием заказчиков были разработаны определённые библиотеки общего назначения, покрывающие основные нужды, специальный АРМ для проектирования (в том числе, и совместного).
"Бизнес-аналитик" — это попытка уточнить понятие "системный аналитик" в том плане, что это такой аналитик, который хорошо разбирается в предметной области, но как и всякий аналитик, имеет техническое образование, поэтому способен переводить требования заказчика на язык теории систем.
Но! Заковыка и большая проблема заключается в том, что с точки зрения системного анализа, мы должны провести этот самый анализ и получить на выходе чёткую спецификацию предметной области в терминах этой самой пресловутой теории систем. (А кто-нибудь видел эту самую теорию систем в лицо, а?) И тогда с заказчиком можно будет разговаривать уже на языке теории систем, то есть — на уровне системных компонентов и конкретных алгоритмов, наполняющих конкретную систему.
То есть!
Что является результатом системного анализа? Некая общая модель, то есть — описание некой обобщённой системы на концептуальном уровне. Концептуальный уровень описывает, фактически, семейство различных моделей уже логического уровня (различного уровня сложности, с различным набором компонентов, с различающейся логикой работы отдельных компонентов), реализующих общую модель концептуального уровня. Концептуальный уровень отвечает на вопрос ЧТО (делает данная система). Логический уровень отвечает на вопрос КАК (она это делает). Разработчику сообщается именно конкретная модель логического уровня. А уже он предлагает и реализует различные модели физического уровня в рамках выбранной модели логического уровня.
Беда! Противоположные требования относятся к различным моделям логического уровня. Нельзя одновременно делать разные системы. Здесь делается принципиальная ошибка. Но на каком уровне присутствует эта ошибка? Возможно, на логическом. Значит, какой-то заказчик плохо понимает свою же область. Но это сомнительно. Значит, проблема лежит на концептуальном уровне, и имеются проблемы с формализацией предметной области.
Без конкретных примеров довольно трудно представить дальнейший ход событий. Можно представить и сценарий с возникновением трёх различных команд для работы с определённым заказчиком и дополнительной центральной командой для работы над общей частью, и сценарий с параметризацией группы компонентов и выборе учётных параметров под конкретного заказчика в момент первого запуска системы, и, даже, сценарий, где заказчику объясняют, где заказчик ошибся (вдруг, какое-то требование неуместное?).
Но! С точки зрения системного анализа, само понятие требования выглядит крайне сомнительным. Какие-могут быть новые/неизвестные требования, если мы провели системный анализ, выявили все требуемые алгоритмы? Мы должны придти к заказчику уже с готовым набором моделей логического уровня, где все потенциальные требования уже учтены, и нужно выбрать из списка ту модель, которая лучше всего подходит заказчику в данный момент. В результатах системного анализа также хранится информация о том, сколько и какая модель реализуется или трансформируется из другой модели и, вообще, трансформируема ли (а то, если трансформировать нельзя, то о чём речь?).
bb17
С заказчиком никогда не придётся разговаривать на языке теории систем.
У заказчика область определения - бизнес структура и бизнес процессы в функциональных границах его бизнеса. Если бизнес заказчика не системный анализ (такое случается), то ему нет смысла (непрофильно и дорого) содержать системных аналитиков в области автоматизации его бизнеса.
Собственно, БА должен согласовать/разработать требования, а затем бизнес процессы и передать их системному (функциональному, техническому) архитектору для разработки архитектуры системы, и далее - по структуре разработке, внедрению, эксплуатации, обслуживанию. В процессе разработки, испытаний, сдачи заказчику БА должен согласовать с заказчиком, что требования выполняются и реализация процессов соответствует. Затем начинается песня о доп. требованиях.
OlegZH
Очень жаль. Всё могло бы быть иначе.
Lis777
"Я всегда задаю вопрос на собеседованиях: если у вас 3 заказчика и они вам говорят противоположные требования к системе, что вы будете делать? По ответам всегда понятно, имеет ли кандидат реальный опыт работы БА."
А какой ответ верный?
Я бы их вместе собрала пусть (передерутся) договорятся))) Опыта у меня нет, я ток учусь. И прав тоже на Хабр нет)) Я могу пока только под свежими статьями комментировать и только под комментами других пользователей - это так дискриминационно(((.
Сейчас буду делать домашку по CRISP-DM. Попробую систематизировать не системное. Там как раз описаны ситуации когда на выходе мы получаем не то, что хотел заказчик. И по схеме в этом случае мы должны вернуться в исходную точку - к бизнес анализу. И вновь пройти все этапы от сбора данных, определения целей и методов и т.д. до оценки результата. И так по кругу, до тех пор пока Заказчик не будет удовлетворен результатом. И только после этого наступает этап внедрения.
Так что то, что Вы описываете как не системное поведение Заказчика(ов) является обычным процессом работы с данными. И даже утверждение "если трансформировать нельзя " (или реализовать "хотелки" Заказчика), тоже является частью методологии работы с данными. Системный анализ предусматривает возможность неоправданности реализации тех или иных проектов, в этом случае, в идеале, это выяснить на этапе сбора данных и первичного анализа, а не на этапе внедрения.
Согласитесь, Заказчику лучше сразу узнать, что его идеи не реализуемы или не оправданны, чем потратить месяцы на анализ и разработку, привлечь кучу специалистов, купить железо, выделить вам носителей hard scills из своей штатки и, в итоге, получить нерабочий продукт. А потом узнать, что он изначально был не реализуем.
Хороший системный аналитик данных на 50% состоит из опыта и на 50% из знаний. У меня нет ни того ни другого - я плохой аналитик. Поэтому процесс обучения в системном анализе бесконечен. Опыта недостаточно - нужно все время учиться. И если в чем то Вы перестали видеть систему, то значит пора учиться ее видеть...
Киньте помидоркой - домашку легче будет сделать))
ITatianaEgorova Автор
А какой ответ верный? Я бы их вместе собрала пусть (передерутся) договорятсяНа мой взгляд это самый верный ответ, в том плане, что БА должен помогать заказчикам договорится (свести их в одной переписке, комнате, чате) - т.е. занимать проактивную позицию, а не ждать финального ТЗ и не работать "с одним из них самым главным". И с другой стороны БА не должен брать на себя эту ответственность - решать и договариваться должны Заказчики. Иногда слышу варианты: я решу сам что лучше для системы и впишу в ТЗ. А потом на ПСИ сюрприз сюрприз ))
Lis777
Спасибо за пояснения. У нас на работе бывают очень жаркие дискуссии и не всегда они приводят к лучшей реализации. Иногда после совместного решения проблемы только увеличиваются, иногда директор принимает решение, которое изначально не оптимально. Решение директора - реальность в которой приходится жить. Она так видит. И если коллективные решения мы можем пересмотреть после реализации, то решения руководителя безапелляционны.
ITatianaEgorova Автор
Ну в этом тоже реальность жизни. Изменить то, что мы можем. Принять то, что не можем изменить, и так далее )
Заказчики всегда не согласны друг с другом, и всегда не просты. Это реальность профессии.
OlegZH
А где же стандарты? Руководящие документы?