При "проработке нефункциональных требований", ИТ аналитик сталкивается с проблемой: "надежность/доступность системы должна быть 99.5%", "время открытия страницы должно быть 3 секунды". А почему не 99.9% или 99.99999% или не 1 или 0.0001 секунды ? В реальности, должен быть достигнут баланс обеспечения качества между потерями бизнеса от необеспечения и расходами на обеспечение.
"Проработка нефункциональных требований" на практике является поиском обеспечения этого баланса, для чего нужно выяснить не только бизнес-потери от необеспечения, но тщательно спроектировать модели обеспечения качества (что часто является работой ИТ-аналитика) и оценить стоимость их создания и владения.
В статье описана методика проработки качества ИТ систем на примерах для аспектов надежности/доступности, производительности и времени отклика.
Статья отражает как прорабатывать детальные требования, откуда брать их обоснования и почему важно строить синхронизированный процесс проектирования бизнес-процессов и поддерживающих ИТ систем.
И как следствие, почему OpenAI не может создать детальные требования.
“Чтобы что” - это что? Как научить аналитика-проектировщика, что является обоснованием функциональных требований, а что нет? Когда заказчик отвечает на вопрос “чтобы что”, как понять, является ли это ответом? Я не нашел книг, где это было бы описано понятно, сжато и лаконично. Чаще всего описаны абстрактные рассуждения, в применении которых на практике возникают проблемы. В статье на примерах разбирается как находить причину требований, какие они бывают, а что не является причиной вовсе.
Вопрос обязательности умения/знания/понимания программирования для ИТ-аналитика-проектировщика вызвал жаркие дебаты в профильных группах. Приводились два вида аргументов:
Люди не всегда понимают, что им говорят/передают другие люди. Например, читая книги я частенько сталкиваюсь с сплошными абстракциями (что авторы на самом деле имели в виду - неясно, ты должен догадаться сам, при этом авторы оставляют за собой право судить, правильно ли ты догадался или нет). Как же передавать смысл понятным образом и давать понятные определения - вот о чем статья.
“Аналитик, проанализируй мне эту задачу” - говорит бизнес-заказчик. Что он имеет в виду? Анализ - это всего лишь метод исследования, характеризующийся выделением и изучением отдельных частей объектов исследования (по википедии), но бизнес в своих словах подразумевает нечто большее, чем просто анализ.
Что делает ИТ-аналитик и в чем ценность его работы для бизнеса? Пробуем разобраться.
ИТ-аналитик в статье - это роль, которую может выполнять выделенный сотрудник, а может и разработчик или любой другой сотрудник.
Забегает молодой парень в больницу:
— Доктор, сделайте мне кастрацию, срочно!
— ???
— Срочно, доктор, некогда объяснять!
Доктор делает кастрацию. Наутро парень приходит в себя от наркоза, его спрашивают, в чем дело, собственно?
— Понимаете, я собираюсь жениться на еврейке, у них так принято по религии.
— Так может быть Вам нужно было обрезание?
— А я что сказал?!!!
Большая часть проблем возникает из-за недопонимания. Вы ставите задачу подчиненному или смежникам, а потом ругаетесь, потому что люди сделали не то, не так, потому что не так вас поняли. Сталкивались с таким? Если вы менеджер и решение задачи входило в ваш круг обязанностей, то наверняка знаете, что неверное исполнение — это ваша ошибка, а не ошибка исполнителя.
В заметке собран каркас из вопросов, ответы на которые стоит записать в задаче если вы задачедатель. Если вы исполнитель, то ответы на эти вопросы помогут лучше понять задачу. Для большинства вопросов собраны примеры из практики, негативные и позитивные.
Конспект книги “Одноминутный менеджер и обезьяны” (Берроуза Хэл, Онкена Уильям младший, Бланшар Кеннет).
В книге И. Адизеса “Стили менеджмента” есть такой герой — Пожарник. Это специалист, которого повысили. Но он по прежнему все старается делать сам. «Чтобы сделать хорошо, сделай это сам» — его девиз.
Этим менеджерам кажется, что управление включает решение всех сложных вопросов из-за чего они оказываются завалены проблемами — “мячиками” задач своих сотрудников. Менеджер становится узким горлышком, что приводит к снижению производительности всей команды.
Книга в первую очередь для таких менеджеров, выросших из исполнителей о том, как ставить задачи своим сотрудникам, не допуская собственной перегрузки, но чтобы при этом не терять контроль.
Вдруг мы понимаем, что Jira превратилась в помойку. Каждый второй РП настраивал Jira как ему было удобнее бесконтрольно. А когда проект начал гореть, начал тушить пожары вручную, оставляя задачи в трекере в каком-то состоянии, далеком от завершения. Если в проекте создан полноценный CI/CD, то большая часть задач на разработку будет в правильном финальном статусе, но остальные…
Часть проектов заморозилась, часть отвалилась, РП выгнали, но задачи в Jira не почистили. У вас на руках 10-20 идущих “проектов” и нужно быстро понять где больше болит.
Сопоставив опыт участников посиделок КиФБ (клуб имени Фрэнсиса Бекона) в решении этой задачи, мы представили этот опыт в записанном виде (за что спасибо всем участникам).
Хорошая книга о коммуникации между людьми. Немного теории о взаимопонимании (с которой вы, возможно, ознакомились благодаря другим книгам этого автора). У каждого есть мозг рептилии (бей или беги), мозг млекопитающего (эмоции и набор условных рефлексов) и мозг человека (рациональное мышление). Любой стресс, в том числе стресс во время коммуникаций, производит эффект «захвата миндалины», который понижает уровень мышления: человек перестает мыслить рационально. Типовые ситуации вырабатывают рефлексы, например, рефлекс отторжения, когда очередной продавец пытается вам что-то втюхать.
Когда вы продаете что-либо (свою идею или свой продукт) или вам нужно решить проблему, убедив собеседника в чем-то, он часто оказывается в ловушке мозга рептилии или млекопитающего из-за стресса и неосознанных рефлексов, которые строят стены коридора, не ведущего к вашей цели.
В книге описаны техники преодоления условных рефлексов, но к этим техникам нужно привыкать. Чтобы не забывать про это, в этой статье сделан краткий конспект для регулярного повторения.
В книге «Современные методы описания функциональных требований к системам» Алистер Кобёрн описал один метод написания части постановки задачи, а именно метод use case.
Что это такое? Это описание сценария взаимодействия пользователя с системой (или с бизнесом). Система при этом выступает как черный ящик (и это дает возможность разделить сложную задачу проектирования на проектирование взаимодействия и обеспечение этого взаимодействия). При этом вводятся стандарты нотации, что обеспечивает простоту прочтения в том числе не участникам, и позволяет делать некоторые проверки на полноту и соответствие целям стейкхолдера.
