Как нетехнический человек может научиться писать спецификации для небольших проектов?

Как нетехнический человек может научиться писать спецификации для небольших проектов?

Мой друг пытается передать какую-то разработку статистического проекта.

В частности, он много работает в Excel и хочет передать сценарии для создания того, что он сейчас делает вручную.

Тем не менее, мой друг крайне нетехнический. Он плохо пишет технические характеристики.

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

Первый аутсорсинговый проект - провал. Я думаю, что он переписал некоторые детали, но не описал угловые случаи. Тот и / или наниматель, которого он нанял, не продумывал угловые случаи и не задавал соответствующие вопросы. Я не уверен. Я связался с ним по IM, и мне потребовалось полчаса, чтобы выкопать описание, которое должно было занять пять минут или меньше, чтобы описать. Я написал сценарии для него в конце, но не изучал, почему его процесс с кодером не удался.

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

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

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

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

Если ваш друг или собирается попросить о создании многочисленных программных инструментов или намеревается заключить с ними контракт, он должен научиться писать требования к программному обеспечению, по крайней мере, на уровне бизнес-целей и концепции операций. Карл Вигерс (Karl Wiegers) - две ведущие книги по разработке требований к программному обеспечению - « Требования к программному обеспечению» (2-е издание) и « Подробнее о требованиях к программному обеспечению: острые проблемы и практические советы» . Я ожидаю, что большинство людей, которых он наймет, захотят какой-то документ, описывающий систему, по крайней мере, на уровне бизнес-целей или концепции операций, и эти книги идут на это. Они также рассказывают о том, как и почему других аспектов разработки требований, которые, как я подозреваю, должен был бы пройти хороший разработчик в начале проекта.

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

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

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

Когда мне нужны спецификации от нетехнического клиента, я обычно прошу их написать простым языком, чего именно они хотят достичь. Как в «приложение должно делать от A до B, когда я нажимаю C, но только если D». Дополнительный бонус за «потому что D означает, что ...».

На самом деле «возьмите этот столбец и запустите среднее значение по нему». это шаг в правильном направлении. Лучшим объяснением будет «Таблица содержит это и то» (если структура предопределена); «Получите среднее значение X». В принципе, наименее технический способ возможен без потери деталей.

Другими словами, опишите идею, а не реализацию.

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

Если нет никого, кто достаточно заботится и понимает процесс, проект в любом случае потерпит неудачу.

Он может попытаться использовать раскадровку .

Пусть он запишет список вещей ( историй ), которые приложение должно будет выполнить, и в этом списке подробно расскажет о функциональности каждой истории.

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

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

Аминь. Это также объясняет, почему:

нанятый им кодер не продумывал угловые дела и не задавал соответствующие вопросы.

Понимание требований - самая трудная (и самая дорогая) часть большинства программных проектов. Когда нетехнические лица пишут требования, они часто документируют только обходной путь, который хотят заменить («откройте Excel, нажмите на ячейку B3 ...»). Лучшее, на что они могут надеяться, - это точная копия их текущей сложности!

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

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

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

нанятый им кодер не ... задавать соответствующие вопросы

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

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

• Для начала предоставьте им несколько простых обзоров итеративных и гибких методологий разработки (подойдут статьи из Википедии), чтобы они могли понять, как это должно быть.
   
• Чтобы помочь им понять прошлые неудачи, предоставьте им несколько простых обзоров Waterfall / Big Design Up Front (те, которые включают критику - опять же, статьи из Википедии) - они, как правило, довольно хорошо объясняют, как трудно определить вещи правильно впереди

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

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

Это отличается - кажется, намного проще, чем указание веб-приложения. Это логичный процесс. Это легкий материал.

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

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

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

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

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

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

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

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

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

Короче говоря, суть в том, что изучение вашего языка - это не работа вашего клиента, а изучение вашего языка.