Люся Сидорова хотела выйти замуж по расчёту... Но не смогла. Она гуманитарий.Так уж сложилось на постсоветском пространстве, что большую часть требований пишут Product Manager, Business Analyst или т.п. персоны, а технарей к составлению требований допускают редко. Технарям достается роль в оценке хотелок. При этом почти всегда сперва пишутся требования и логика работы приложения, а затем его передают на оценку технарям.
Напомню про график из предыдущей публикации. Перетраты на исправлениях до 5 раз возникает когда технари и постановщики задачи начинают футболят в друг друга требованиями и оценками.
💊 Самая эффективная рекомендация! Можете ее показать своим менеджерам. Обьясняйте технарям всю задумку и идеи стоящие за этой задачей. Почти всегда инженер, который не просто делает работу, но и понимает зачем ее делает, предложит как срезать острые углы и может предложить слегка видоизменить требования чтобы сэкономить на этапе разработки.
После прохождения этого этапа в отношениях, можно переходить к более высокоуровневым вещам. Например, обучать базовым инженерным практикам нетехнических постановщиков.
В моем опыте были объяснения:
- как работает протокол HTTP, WebSocket
- как ведет себя браузер после запроса загрузки страницы и до закрытия табы
- что такое сессия пользователя
- как происходит балансировка нагрузки и почему два запроса подряд на разных серверах могут выполняться
- что за магия с cookies и local storage
- и многое друго...
❓Почему❓ Вот хочет реализовать постановщик логику работы чатов на WebSocket. В его мире “ДО” нажатие кнопки “отправить сообщение” было неразрывно связано с тем фактом, что сервер получил сообщение в риалтайме и обработал его. Когда объясняешь, что банально в момент отправки соединение может быть не установлено, может быть в процессе реконнекта и тп, то после этого человек уже формирует требования с учетом разных состояний соединения! Когда объясняешь, что у могут быть синхронные и асинхронные запросы, а пока ответ летел клиенту с сервера, то состояние на сервере могло уже поменяться, то качество проработки edge cases и fail-сценариев в требованиях вырастает в разы. Это и создает экономию на этапе написания требований.
Итого, на этом этапе рекомендую составить список “нюансов” из доменной области, задокументировать их и обьяснить детали. Также неплохо иметь чекисты перед выдачей требований. “Учтены ли таймауты в ответах”, “Учтены ли ошибки и проработана ли реакция на них“ и подобные чеклисты будут верными помощниками.
@noTieInIT
