Лучший способ общаться с программистом для определения проекта? [закрытый]

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

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

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

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

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

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

• Дают подробные примеры. Программисты называют их пользовательские истории или варианты использования.
• Очевидно указывают Ваши требования. Я должен получить имя сотрудника, адрес, и номер телефона от базы данных намного лучше тогда, я должен получить информацию о сотруднике.
• Включают все, что Вы хотите, чтобы он сделал теперь, и что Вы думаете, что могли бы хотеть в будущем.
• Располагают по приоритетам. Сообщите нам то, что требуется, что Вы хотели бы, и что неважно.

С моей технической точки зрения:

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

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

Некоторые примеры:

• Клиент хочет приложение "точно так же, как MS Word", когда то, в чем он нуждается, является всего несколькими ярлыками для форматирования его текста. Технический специалист должен тогда поместить клиент перед документом MS Word и заставить его показать точно, в каких функциях он нуждается.
• мой персональный недавний опыт: клиент продолжает спрашивать, "какой CMS Вы используете?" - в то время как действительно никакой out-of-the-box так называемый CMS не соответствовал бы своим потребностям, плюс, или A), он просто повторяет "CMS" как попугай, потому что ему сказали так B), он использовал или услышал о, некоторое программное обеспечение, которое назвало себя "CMS". Действительно, технический специалист не должен стараться избегать этого недоразумения путем лжи (который является самым легким выходом, но обратная вспышка сделает его хуже). Снова, практическая демонстрация некоторой существующей функции того, что клиент имеет в голове не имея возможности для помещения слов на него, должна привести к решению, и, снова, общему словарю.

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

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

Избегайте предположений. Обстоятельно объясните с таким количеством детали, как Вы можете, что Вы хотите быть сделанными. Удостоверьтесь, что на каждый вопрос можно ответить с "да", "нет", или X, где X категорическое значение. Ничего не оставляйте до интерпретации или любого maybes в Ваших инструкциях.

Определяют каждый объект, который должен быть доступным конечному пользователю, его поведение и стиль. Удостоверьтесь, что ВЫ знаете точно, что Вы хотите, прежде чем Вы попросите, чтобы кто-то кодировал его.

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

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

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

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

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

Через их наушники.:)

USB 2.0 (или RS232 для более старых).

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

Как я сказал... Требования, Требования, Требования.

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

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

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

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

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

Проще говоря, я знаю то, что я хочу сделанный, но я ничего не знаю о превосходном программировании

, первый шаг должен признать, что Вы нуждаетесь в помощи;-)

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

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

, поскольку другие отметили, необходимо сказать программисту, что Вы, пользователь, хотите быть в состоянии сделать. Не , как , чтобы сделать это, но , что программное обеспечение позволит Вам сделать. "Что" является требованиями, "как" дизайн.

Прежде всего, тем не менее, программист должен понять бизнес-домен , который лежит в основе requiements. Без этого основания он действует в концептуальном вакууме.

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

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

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

РЕДАКТИРОВАНИЕ: и если у Вас есть больше чем одно приложение, которое будет создаваться со временем, выберет разработчика, которого Вы любите и что Вы думаете, что могли работать с за длительный срок. Постройте отношения с ним на основе взаимного доверия и уважения. Существует много действительно хороших программистов с нулевыми административными навыками; избегайте их, поскольку они сведут Вас с ума в конечном счете.

Некоторые хорошие предложения выше из других плакатов.

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

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

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

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

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

Выезд Преимущества “As пользователь, я want” пользовательский шаблон истории .

Hope это помогает, Bruno Figueiredo http://www.brunofigueiredo.com

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

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

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

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

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

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

Некоторые могли бы не согласиться, но я обычно нахожу, что блок-схемы обычно не очень ценны.

<sarcasm> Обеспечивают специфические особенности и детали, и Вы получите точно, что Вы попросили, не, что Вы хотели .</sarcasm>

Серьезно, детали хороши в какой-то степени.

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

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

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

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

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

Теперь для проблемы курицы-или-яйца. Если Вы не являетесь техническими, как Вы находите хорошего разработчика программного обеспечения? Спросите людей, которых Вы знаете для рекомендаций. Если необходимо взять интервью у кого-то, попросите, чтобы они принесли демонстрационный документ требований и функциональную спецификацию. Посетите веб-сайты, которые они разработали. Безусловно, это устранит много полностью определенных программистов, поскольку многие не могут совместно использовать этот тип материала из-за проблем конфиденциальности. Но Вы в состоянии, где необходимо знать, что они могут понять бизнес-потребности и создать продукт для решения тех потребностей.

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

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

Удачи!

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

Также предпосылки. Удостоверьтесь, что Вы говорите программисту, под какой средой это должно работать, он для рабочего стола или сервера и сколько поршня и что операционная система?

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

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

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

Шаг 2. Извлеките все существительные в вышеупомянутых проблемных операторах и предоставьте точные определения условий. Чем более простой термин, тем более точного определения он требует, потому что люди имеют в виду разные вещи.

Шаг 3. На большом листке бумаги тянут поля для каждого, называет, и соедините поля со строками или стрелками, где он имеет отношение. Проигнорируйте (0..*), вещь, но схема должна быть похожей на следующее. Помните без хорошего определения условий, схемы не означают много.

_{(источник: agiledata.org )}

Шаг 4. Затем, придуманный простые сценарии конечный пользователь может взять к программе наряду с ожидаемыми выводами из программы. Например:

1. пользователь нажимает 1 кнопку.
2. система должна отобразиться "1". (без кавычек, но включая период).
3. пользователь нажимает + кнопка.
4. пользователь нажимает 2 кнопки.
5. система должна отобразиться "2". (без кавычек, но включая период).
6. пользователь нажимает = кнопка.
7. система должна отобразить сумму 1 и 2 с периодом, который равняется "3"..

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

Шаг 5. Встречайтесь с программистом регулярно (каждые две недели, например) и определяйте, на котором должна работаться задача и на котором не должна работаться задача. Важно определить, что НЕ сделать, потому что без таких инструкций программисты склонны делать то, что они думают, право , который называют Ковбоем, Кодирующим. Обновите условия, схему или варианты использования в случае необходимости.

Шаг 6. Когда Вы встречаетесь с программистами, требуете, чтобы Вы хотели видеть саму программу и игру вокруг с ним. Проверьте, делает ли программа то, о чем Вы договорились. Скажите им, что Вы любите и что Вы не любите.

Только для добавления к тому, что другие сказали здесь необходимо быть НАМНОГО более конкретными, если это - произведенный на стороне проект по сравнению с внутренним проектом. И я не забочусь, производите ли Вы на стороне в Индию, Китай или парней вниз улица - если Вы не конкретны, Вы, вероятно, получите что-то, что встретит абсолютный минимум того, что Вы ставите бумагу, но не, что Вы хотели. В доме программисты, более вероятно, запросят разъяснение и сделают то, что Вы имеете в виду вместо только, что Вы запросили.

По моему опыту, это - плохая идея попытаться определить то, что Вы хотите впереди, бросаете его по стене и ожидаете, что программист поставит exectly, что Вы хотите. Самая твердая вещь о создании программного обеспечения, это - сложность, если Вы определяете точно, что Вы хотите Вас, вероятно, обеспечили столько же детали как тогда, когда Вы запрограммировали его сами.

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

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

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

Используйте методологию ТОЛПЫ.

Описывают вещи с точки зрения "Пользовательских Историй" (Что пользователь хочет сделать).
Описывают, как "Пользовательские Истории" Взаимодействуют друг с другом.

Позволяют разработчику выяснить как.

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

Спецификации/Требования и методология водопада, как показывали, снова и снова не работали (или если я говорю, предоставляют метод для того, чтобы точно запланировать проект).

Независимо от того, что Вы делаете, запишите его, и знак это.

Тогда дают его им и соглашаются быть сохраненным к инструкциям относительно бумаги.

Самая большая проблема мы имеем, поскольку разработчики являются неполными или неправильно переведенными спецификациями, и что мы действительно хотели бы, листок бумаги, который совершенно прозрачен, и необходимо быть в состоянии приехать к нам с любой проблемой в проекте, и это должно быть упомянуто в документе в crystal-clear-as-used-by-lawyers терминологии.

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

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

План этап, выйдите из него, сделайте это. Что-то пропущено, это переходит к более позднему этапу. Вам не удается сделать это, и это никогда не будет поставляться.

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

При создании дома, каждый не делает "крыла это".

А Удобный Домом человек создал дом, который сделан, поскольку они решаются о том, как сделать это, занимает годы для создания. </rant>

Запишите документ требований продукта.

http://en.wikipedia.org/wiki/Product_requirements_document

Read этот ряд Joel Spolsky

http://www.joelonsoftware.com/articles/fog0000000036.html

И вот пример

http://www.joelonsoftware.com/articles/WhatTimeIsIt.html