Рубрика «требования» - 4

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

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

Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

  1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
  2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
  3. “Бизнес” и “разработка” говорят на разном языке. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

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

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

Ниже — обзор продуктовых техник, которые могут в этом помочь.
Читать полностью »

Обратная сторона мобильных клиентов — сервер.

Введение

Не открою секрета, что разработка мобильных приложений в тренде – этому способствует стремительное техническое развитие: мобильные устройства с каждым годом улучшаются по всем характеристикам и становятся доступнее для широкого круга людей. Почти каждый, кто имеет на руках мобильный гаджет (будь то смартфон, коммуникатор или планшет) пользуется приложениями: браузером, клиентом электронной почты и мгновенных сообщений, играми, бизнес или финансовыми программами. И зачастую от пользователей скрыто то, что многие из приложений взаимодействуют с удаленным сервером: обмениваются с ним данными через Интернет.
По роду деятельности (Java разработчик серверных приложений) мне в команде приходится разрабатывать сервера для мобильных клиентов (за последние 2 года участвовал в реализации 3-х таких проектов для зарубежных компаний). Определился набор Java-технологий для решения задач такого рода, который варьируется в зависимости от требований и целесообразности (другими словами — желания), благо свобода при выборе технологий позволяет экспериментировать. Сформировавшейся точкой зрения и опытом хотел бы поделиться с сообществом.Читать полностью »

В прошлой статье От инженера до руководителя. Часть 1: Чувство справедливости я рассказывал о чувстве справедливости. Возвращаясь к ней, хочу повториться, что чувство справедливости является основополагающим моментом. И если мне вздумалось о чём-то рассказать, то каждая моя неточность, а тем более ложь, неподкреплённое фактами мнение, орфографическая ошибка и агитация нашли бы своих недовольных. Что, собственно, можно наблюдать и тут и в жизни ежедневно. Одно дело придерживаться конкретной стороны в холиваре (парадигме, стандарте, процессе), получая тумаки от одних и поддержку от других; и совсем другое дело — описывать и следовать своей собственной точке зрения, опыту и выдерживая свою стилистику. Это — сродне минному полю, где известны правила игры, но за всё, что делаешь, несёшь сам ответственность. Такая же разница существует между исполнителем и руководителем, где последний при своей ошибке получит пинок из-за проявленой “несправедливости” и набьёт немало шишек сам, если будет ошибаться, хотя и спасая этим идущих за ним. Поэтому в моём понимании лучше набивать шишки загодя, с уровня сотрудника, ощупывая путь мягкими частями тела, не получая дополнительных пинков сзади — главное не отставать и не идти против руководителя, впрочем, если он не до конца неправ и не ведёт всех на обрыв. В противном случае, попридержите коней, ведь вы — рабочая лошадка — в одной упряжке. О том, как как поставить правильную цель и как исполнять работу совместно с другими и пойдёт речь в этой статье.

От инженера до руководителя. Часть 2: Делегирование и постановка задачи
Читать полностью »

В основе разработки ПО авионики лежит основополагающий стандарт RTCADO-178B. Несмотря на первый взгляд на его отстранённость от непосредственной рутины программиста, он описывает весь процесс разработки и выдвигает требования к подобному ПО. Тем не менее, в данной статье речь пойдёт и о том, как всё происходит на самом деле, на основе личного опыта разработки систем контроля и управления полётом, систем посадки и пр. для самолётов и вертолётов.

image

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js