Насколько важно знать функциональность перед написанием кода?

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

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

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

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

Мой вопрос: как бы вы занялись разработкой, если не знаете полностью функциональность приложения?

ОБНОВИТЬ

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

Укороченная версия:

Зная, что делать, зная вашего клиента.

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

Длинная версия:

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

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

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

Вот почему функциональные и нефункциональные требования должны быть написаны людьми, которые полностью понимают предметную область. Как правило, сбор требований включает в себя:

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

2. Люди, специализирующиеся на управлении проектами,

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

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

Что касается вашего конкретного случая, вы сами описываете причину проблемы:

Мы боремся с проектной документацией, так как требования не будут понятны.

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

Зная это, вы должны действовать по-другому:

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

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

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

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

Используя Waterfall, вы обязуетесь:

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

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

Приличное сравнение « Водопад» против «Agile» было написано некоторое время назад, давайте возьмем из него пару цитат, которые высветят ваши проблемы:

Отсутствует знак:

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

Привязанный...

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

... и не может двигаться

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

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

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

Это не так, как это работает. Одним из предметов моего текущего образования является анализ и отношения с клиентом. Акцент всегда был на четком определении проекта. Вообразите это:

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

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

Вот некоторые вещи, которые помогут преодолеть проблемы:

1. Улучшить связь между двумя командами. Попросите другую команду сжать требование до 3 слов, и тогда программист точно выполнит эти слова. Слова просто должны быть правильными. Ничто не будет реализовано без этих слов. Каждое слово дает вам 2000 строк кода. Реализация начинается, когда новое слово известно.
2. Если слово не сразу понятно вашим программистам, им разрешается задать один вопрос . Вопрос опять должен быть правильным. Требуется немедленный ответ - ответ не может ждать в обе стороны от другой стороны мира, но его нужно знать заранее. Реализация начинается сразу после получения ответа, и ответ будет сопровождаться письмом.
3. Если во время реализации существуют неясные или нечеткие требования, способ их решения - сначала взглянуть на (существующие) 3 слова. Если это все еще неясно, то программист делает наилучшее возможное предположение . Любая задержка в этом процессе абсолютно запрещена; и просить помощи у другой команды - неправильный способ решить ее - у них уже был шанс изменить требования, решив правильные 3 слова.
4. Если после всего этого требование все еще неясно или невозможно выполнить, правильный способ справиться с этим - отклонить те 3 слова, которые вызвали проблему, и перейти к следующим словам. Любые отклоненные слова будут собраны и переданы другой команде, и им нужно будет изменить слова перед повторным вводом их в систему. Отклонение слов всегда сдвигает крайний срок, и реализация должна быть запланирована снова.
5. Команды должны оцениваться на основе количества отклоненных слов. После того, как требование выполнено, оно фиксируется навсегда и больше не может быть изменено . Любые попытки изменить уже реализованные функции будут отклонены.
6. Фактическая проблема с этим вопросом заключается в том, что предполагается, что больше информации облегчает реализацию. Это неправда. Чем больше свободы у ваших программистов, тем проще реализация . Сжатие требований позволяет передавать большие объемы информации, не ограничивая слишком много того, что разрешено делать программистам.