Каков наилучший набор деталей, чтобы дать программисту возможность определить проект?
Проще говоря, я знаю, что хочу сделать, но я ничего не знаю о программировании, и поэтому лучший способ определить мой проект для программиста, чтобы он дал мне то, что мне нужно. т.е. краткое описание проекта, блок-схемы?
Избегайте предположений. Запишите с такой же детальностью, как вы можете, что вы хотите сделать. Убедитесь, что на каждый вопрос можно ответить "да", "нет" или X, где X является окончательным значением. Не оставляйте в своих инструкциях что-либо, вплоть до толкования или любых мейнов.
Укажите каждый элемент, который должен быть доступен конечному пользователю, его поведение и стиль. Убедитесь, что вы точно знаете, что хотите, прежде чем попросить кого-нибудь его закодировать.
И убедитесь, что ваша документация хорошо организована. Я уверен, что вы можете найти много белых документов по бизнес-требованиям в Интернете.
Напишите документ с требованиями к продукту.
http://en.wikipedia.org/wiki/Product_requirements_document
Прочтите эту серию Джоэлем Спольским
http://www.joelonsoftware.com/articles/fog0000000036.html
И вот пример
Используйте методологию SCRUM.
Опишите вещи в терминах "Истории пользователей" (то, что пользователь хочет делать).
Опишите, как "Истории пользователей" взаимодействуют друг с другом.
Пусть разработчик выяснит, как.
Получить его/ее, чтобы продемонстрировать, что они сделали через регулярные промежутки времени. Если вы передумали или не пойдет так, как вам нравится, вы можете обновить разработчика, где он ошибается, и он может обновить свое направление.
Спецификации/Требования и методология водопада были показаны снова и снова, чтобы не работать (или, я должен сказать, предоставить метод для точного планирования проекта).
По моему опыту, это плохая идея, чтобы попытаться определить, что вы хотите впереди, бросить ее через стену и ожидать, что программист выполнит то, что вы хотите. Самое сложное в создании программного обеспечения - это сложность, если вы точно определяете то, что хотите, вы, возможно, предоставили столько деталей, сколько запрограммировали сами.
Лучшее, что вы можете сделать, это попытаться работать вместе с программистом. Найдите того, кто может доставить рабочее программное обеспечение короткими приращениями один раз в месяц или раз в две недели. И дайте отзывы о том, что вам нравится, что вам не нравится и что еще вы хотите. Постарайтесь убедиться, что программист дает вам проверенное и работающее программное обеспечение каждый раз, чтобы вы действительно могли видеть, сколько сделано.
Этот способ работы дает вам возможность точно определить, какие функции вы считаете важными. Сначала вы их реализовали. Недостатком является то, что это будет стоить вам больше времени и усилий.
Что бы вы ни делали, запишите его и подпишите.
Затем дайте их им и соглашайтесь с инструкциями на бумаге.
Самая большая проблема, которую мы имеем в качестве разработчиков, - это неполные или неверные спецификации, и нам бы очень хотелось, чтобы документ был кристально чистым, и вы должны быть в состоянии прийти к нам с любой проблемой в проекте, и это должно следует упомянуть в документе в терминологии "кристально чистая, как используемая юристами".
По крайней мере, так мы можем сказать: "Посмотрите, мы сделали то, что вы просили, здесь это написано, ничего не написанного здесь нельзя ожидать от меня, его не происходит".
Это может показаться не совсем приятным, но поверьте мне, вам не нравится, что вы попробуете все труднее понять. И если цель не попадает в газету, не пытайтесь что-то пропустить в дальнейшем, переписывая спецификацию после того, как требования просто приведут к тому, что вы будете раздуты.
Планируйте веху, подпишите ее, сделайте это. Что-то пропущено, оно переходит к более позднему этапу. Вы не можете этого сделать, и он никогда не будет отправлен.
Ты из тех, кто меня убивает FYI, все, кого я знаю, имеют эту проблему. Это отстой. У меня есть партнеры, которые были эффективно шантажированы компаниями, которые переоценивают спецификации, пытаясь проскользнуть в вещах, которые никогда не обсуждались. Вы не можете ожидать, что кто-то сделает что-то, что не было предписано. Это даже не возможно. Возможно, это в фантастической стране или в той "корпоративной реальности", о которой вы всегда ищем, но не в реальном мире.
При строительстве дома никто не "крыло".
A Домашний дом, построенный человеком, который сделан, когда они решают, как это сделать, требуются годы для создания. </& напыщенная GT;
Некоторые могут не согласиться, но я обычно обнаруживаю, что блок-схемы обычно не очень ценны.
Вам нужно найти программиста, у которого есть опыт написания пользовательских приложений для нетехнических людей. Этот человек должен также иметь опыт управления техническим проектом. Он (или она) должен создать с вашей помощью документ с требованиями и функциональную спецификацию, которую вы будете подписывать до начала фактического развития. Человек, который по-настоящему хорош в этом, имеет большой опыт и не будет дешевым, но работать с нетехническими клиентами так сложно для многих разработчиков, поскольку дело с разработчиками для вас.
Даже если вы его подписываете, это не значит, что вещи не могут быть изменены позже. Если вы хотите внести изменения, вы обновите свои документы, и ваш разработчик даст вам новую оценку стоимости и времени.
Теперь для проблемы с курицей или яйцом. Если вы не являетесь техническим, как вы находите хорошего разработчика программного обеспечения? Спросите у знакомых людей рекомендации. Если вам нужно взять интервью у кого-то, попросите их принести пример требований и функциональную спецификацию. Посетите веб-сайты, которые они разработали. Разумеется, это избавит многих полноправных программистов, поскольку многие из них не могут делиться этими вещами из-за проблем с конфиденциальностью. Но вы находитесь в положении, когда вам нужно знать, что они могут понять ваши потребности в бизнесе и создать продукт для решения этих задач.
Если вас не устраивает документ требований и функциональные спецификации, не продолжайте с этим человеком. Все будет ухудшаться, а не лучше. В итоге вы получите хорошие деньги после неудачи.
По-настоящему сложно общаться с большим количеством разработчиков. Как найти врача, найдите тот, с которым вам удобно, который слушает вас и ваши проблемы, и может повторить эти проблемы своими словами.
Удачи!
Лучше всего найти программиста, обладающего талантом при разработке спецификаций у нетехнических клиентов. Рекомендации из уст в уста других клиентов, вероятно, были бы самым надежным способом найти программистов, которые могут это сделать.
Серьезно, это типичный сценарий для всех разработчиков. Клиент обычно не имеет технического фона и очень мало желания вникать в проблемы программирования. Они часто даже не знают, чего хотят, не говоря уже о том, что возможно. Таким образом, на плечи разработчиков приходится преодолевать разрыв, связываться с клиентом и превращать идеи клиентов в технические соображения.
Чтобы все было в курсе событий, я бы рекомендовал выполнять работу на основе T & M итеративным образом. Проводите частые обзоры и демонстрации системы по мере ее разработки, дайте отзывы о том, что вы видите и переоцениваете ценность системы и качество развития, которое вы видите. Потяните вилку, если она похожа на грушевидную.
Я постоянно ошеломлен тем, насколько плохие большинство нетехнических людей придумывают программные решения до их доставки. Я сидел в бесчисленных ранних проектных встречах, где я мог гарантировать, что каждый программист в комнате создает одну и ту же картину в их голове - включая представление о том, как вызовы подпрограмм будут необходимы для определенных функций, - но клиенты на том же собрании не будут " t на одной странице. Слишком часто эта пропасть не становится известной до тех пор, пока клиент не увидит продукт, что именно так описывают программисты на стартовой встрече, и они указывают на некоторые очевидные (для них) дефекты.
Это только болит, если клиент не доберется до продукта до конца разработки. Так что посмотрите на это рано, посмотрите на него часто и дайте отзывы.
Трудно получить сложную идею, например, весь рабочий пакет программного обеспечения в словах, для чего нужен документ требований. Это было сказано в других сообщениях; вам нужно точно указать, что вы хотите сделать, не оставляя абсолютно никаких предположений. Два человека могут представить что-то совсем по-другому из того же объяснения, почему важно указать, что именно вы хотите сделать.
Также необходимы предварительные условия. Убедитесь, что вы скажете программисту, в какой среде он должен работать, это для рабочего стола или сервера и сколько оперативной памяти и какой операционной системы?
Вам не нужно указывать, КАК это работает, что действительно нужно программистам. Вы можете направить его на него, если у вас есть какие-то идеи, но у программиста должен быть опыт или достаточно подготовки для разработки внутренних компонентов.
В действительности, о внешнем, вы должны быть предельно ясны относительно требуемых входов и требуемых результатов, будь то графические пользовательские интерфейсы или программные интерфейсы. Вам нужно знать, чего вы хотите, прежде чем он сможет узнать, что вы хотите!
Просто чтобы добавить к тому, что говорили здесь другие, вы должны быть более конкретным, если это проект, основанный на аутсорсинге, по сравнению с собственным проектом. И меня не волнует, если вы передаете на аутсорсинг в Индию, Китай или ребята на улицу - если вы не конкретны, вы, скорее всего, получите что-то, что будет соответствовать минимуму того, что вы положили на бумагу, но не что вы хотели. В домашних программистах будет более вероятно запрашивать разъяснения и делать то, что вы имеете в виду, а не только то, что вы просили.
Некоторые хорошие предложения выше других плакатов.
Определение основ того, что вы хотите, является очевидным началом. Но по моему опыту, что может также повредить процесс вниз по течению, это когда исключения не рассматриваются. Они почти всегда забываются до тех пор, пока программное обеспечение не будет разработано или не пройдет тестирование. Поэтому приложите немного усилий, чтобы подумать о том, как вы хотите, чтобы программное обеспечение или процесс работали, когда все идет не так. Примеры:
Это может определенно помочь распространить ваш процесс требований в течение цикла разработки с помощью итеративного развития. Вы не всегда знаете, какие исключения вы должны будете обрабатывать. Некоторые из них не зависят от бизнеса, а от технических проблем, таких как поведение пользовательского интерфейса, интеграция с другими системами и т.д. Даже при этом, чем больше требований к качеству, которые вы можете предоставить раньше, тем лучше будет весь процесс.
Хороший вопрос. Пара решений.Лучший способ связаться с программистом для определения проекта?
Вкратце, чтобы помочь дать разработчику большой обзор мазков кистей, в то время как область проекта станет более подробной. В области проекта я обычно описываю представления и обрабатываю их друг с другом. После создания обоих этих документов я открываю проблемы в Github с Zenhub Scrum Boards для управления каждой задачей и приоритетом. Это также помогает назначить несколько проблем нескольким программистам.
Удачи!
Лучший способ указать ваши требования - с точки зрения пользователя. Если вы описываете конкретные варианты использования вашим программистам, это делает его намного понятнее. Нам полезно знать, что пользователь пытается выполнить с помощью нашего программного обеспечения, поэтому мы не строим никаких собственных предположений.
Это действительно спецификация требований и проблема управления. Я бы дал им все, что у вас есть. Попытайтесь четко описать это на простом английском (или любой другой язык). Если вы можете выполнить блок-схему, сделайте это тоже.
Вы должны ожидать, что программист может задать несколько вопросов, а затем уйти, чтобы подумать, но вы также должны ожидать, что они вернутся с большим количеством вопросов для вас, чтобы уточнить требования. Если они не делают этого в течение недели или около того, вы должны проверить их с ними, чтобы дать им возможность спросить.
Если проект поддается этому, вы можете настроить ранние рабочие прототипы.
Вы можете использовать истории пользователей (используемые в методологии SCRUM), чтобы выразить свои потребности пользователю. Они описывают функциональность приложения или часть приложения в точке зрения пользователя. Ответственность программиста заключается в том, чтобы перевести эти истории пользователей на код.
Отъезд Преимущества шаблона пользовательской истории "Как пользователь, я хочу" .
Надеюсь, что это поможет, Бруно Фигейредо http://www.brunofigueiredo.com
USB 2.0 (или RS232 для более старых).
Каков наилучший набор деталей, чтобы дать программисту возможность определить проект?
это зависит от проекта, от вашего понимания того, что вы хотите, и от понимания программистом бизнес-домена. Истории пользователей, примеры использования и описания единичных тестов великолепны, но понимание программистом бизнес-домена является важной основой для всех этих.
Проще говоря, я знаю, что я хочу сделать, но я ничего не знаю о программировании
отлично, первый шаг - признать, что вам нужна помощь; -)
, и так что лучший способ определить мой проект для программиста, чтобы он дал мне то, что мне нужно. i.e резюме проекта, краткое описание проекта, блок-схемы?
ничего из вышеперечисленного - так как вы не программист, вы не сможете точно написать эти технические описания. И вы не должны!
как отмечали другие, вы должны сказать программисту, что вы, пользователь, хотите, чтобы иметь возможность делать. Не так, как это сделать, но то, что программное обеспечение позволит вам сделать. "Что" - это требования, "как" - это дизайн.
Прежде всего, программист должен понимать бизнес-домен, который лежит в основе требований. Без этого заземления он/она работает в концептуальном вакууме.
Как только программист узнает о вашей компании, расскажите о необходимых вам приложениях.
Продолжайте медленно, рассказывайте истории пользователей вместе, рисуйте экраны и делайте макеты для бумаги вместе, соглашайтесь с деталями, необходимыми для работы (по отношению к пользователю) вместе. Объясните программисту, что, поскольку это ваш первый проект, вы действительно хотите участвовать на каждом этапе процесса запуска, но как только вы оба поймете и согласитесь с тем, как приложение должно быть выполнено, включая те тесты, которые он должен пройти в порядке чтобы быть принятым - тогда вы оставите его/ее в покое, пока будете доступны для вопросов.
Не используйте неопытного разработчика для этого первого проекта, поскольку вы будете полагаться на него/нее, чтобы научить вас хорошим практикам.
EDIT: если у вас есть несколько приложений, которые будут построены с течением времени, выберите разработчика, который вам нравится, и что вы думаете, что можете работать в течение длительного времени. Постройте отношения с ним на основе взаимного доверия и уважения. Есть много действительно хороших программистов с нулевыми навыками; избегайте их, так как в конечном итоге они будут приводить вас в норму.
Изложите свои требования. Что вам нужно сделать. Не просто скажите ему, что вы хотите, как конечный продукт, но дайте ему список краткосрочных и долгосрочных целей.
Как я уже сказал... Требования, Требования, Требования.
Нет конкретного способа, которым вы пользуетесь для общения с программистом. Это очень общий вопрос, и вам нужно добавить более подробную информацию о том, что вы хотите, какое приложение вы ищете и т.д.
Я лично много работаю на уровне пользовательского интерфейса веб-сайта и предпочитаю скриншоты с каждым запросом, который мы получаем. В моем случае картина стоит тысячи слов. Человеку, который пишет поисковую систему или искатель, вообще не потребуется скриншот. Я также предпочитаю хорошо написанные технические спецификации на то, что вы ожидаете, когда вы этого хотите, и некоторые примеры.
Кроме того, убедитесь, что вы просмотрели все, что вы указали. В некоторых случаях ваши потребности могут не совпадать с первоначальным описанием.
Дайте им шаги, необходимые для того, чтобы вы могли получить желаемый результат на странице. Если вы видели какие-либо другие страницы, похожие на то, что вам нужно, дайте им пример. Но самое главное быть конкретным о том, что вы хотите! Если вы не знаете, чего хотите, вы не можете ожидать их.
<sarcasm> Предоставьте детали и детали, и вы получите именно то, что вы просили, а не то, что вы хотели .</sarcasm>
Серьезно, детали хороши до определенной степени.
Никогда не предполагайте, что разработчик понимает вашу сделку или даже хочет ее изучить. Я обнаружил, что многие, многие разработчики действительно не хотят понимать бухгалтерские или лучевые науки или какую бы то ни было другую профессию, в которой вы участвуете. Если они занимают какое-то время, чтобы учиться, это только на самом беглом уровне.
Мунданные детали или решения, которые являются основополагающими для вашей торговли или рабочего процесса, не будут очевидны для разработчиков. Нечто простое, как поле или порядок табуляции на странице может быть потерян разработчиком, потому что им никогда не приходилось вводить ваши данные. Или факт, связанный с двумя частями данных, может быть очевиден для вас, но они могут казаться полностью отключенными от разработчика. Возможно, рабочий процесс соответствует определенному шаблону, за исключением случаев, когда происходит определенное событие или ситуация...
Будьте готовы научить их частям вашей профессии (даже если они этого не хотят) и убедитесь, что они понимают, что вы на самом деле делаете. Это та область, в которой я был наиболее устойчив от разработчиков - они склонны думать, что понимают, когда на самом деле они этого не делают. Это не связано с какой-либо злобой с их стороны, просто простой реальностью, что многие задания легко освоить, но трудно овладеть.
С моей технической точки зрения:
Скорее всего, не делайте никаких предположений о том, как должна быть спроектирована/реализована функция X.
Но что более важно, из моего недавнего опыта, что происходит, что владелец/клиент продукта имеет некоторые привычки или использует некоторые инструменты для достижения определенных задач. Затем, вместо объяснения его практического опыта, он абстрагирует то, что, по его мнению, является общей концепцией, и это приводит к сбою связи, когда обе стороны (владелец продукта и техники) смотрят друг на друга как невежественные доки. Вы не можете достичь ничего вместе, пока у вас не будет общего словаря. Остановите разговор, как только что-то станет неясным и попытайтесь определить каждое слово.
Некоторые примеры:
И, наконец, не пытайтесь думать обо всём, слишком много предположений сделать. Работайте итеративно. Программное обеспечение "мягкое", это означает, что он может измениться. Лучше делать небольшие изменения с течением времени, чем быть упрямыми в отношении ранних предположений.
Что касается управления проектами, в последнее время методология SCRUM помогла мне разобраться во всех типах сбоев связи. По крайней мере, из-за своей прозрачности такая методология позволяет увидеть, что может вызвать сбой, прежде чем тратить слишком много времени или денег.
Через наушники.:)
Шаг 1. Опишите вашу проблему простыми английскими предложениями. Он не должен быть подробным, но должен охватывать все аспекты вашей проблемы.
Шаг 2. Извлеките все существительные в приведенных выше постановках задачи и предоставьте точные определения терминов. Чем проще термин, тем более точное определение требуется, потому что люди имеют в виду разные вещи.
Шаг 3. На большом листе бумаги нарисуйте прямоугольники для каждого термина и соедините прямоугольники линиями или стрелками, где они связаны. Не обращайте внимания на (0.. *), но диаграмма должна выглядеть следующим образом. Помните, что без четкого определения терминов диаграммы мало что значат.
(источник: agiledata.org)
Шаг 4. Далее придумайте простые сценарии, которые конечный пользователь может использовать в программе вместе с ожидаемыми результатами программы. Например:
Задача может ссылаться на другие задачи и должна указывать, что система делает при неверном вводе данных пользователем (например, отправляет электронную почту администраторам). Идея состоит в том, чтобы создать тестируемые сценарии, с помощью которых вы и программист можете проверить программу. Эти мини-сценарии называются сценариями использования.
Шаг 5. Регулярно встречайтесь с программистом (например, каждые две недели) и определяйте, над какой задачей нужно работать, а над какой НЕ следует работать. Важно указать, что НЕ следует делать, потому что без таких инструкций программисты, как правило, делают то, что считают правильным, что называется Ковбойским кодированием. Обновите условия, схему или варианты использования, если это необходимо.
Шаг 6. Когда вы встречаетесь с программистами, потребуйте, чтобы вы захотели увидеть саму программу и поиграть с ней. Проверьте, выполняет ли программа то, о чем вы договорились. Скажите им, что вам нравится, а что нет.
Многие программисты, которых я знаю, очень быстрые ученики, и имеют врожденную ловкость для выявления несоответствий, альтернатив и упрощений.
Вы могли бы лучше всего научить его о своем домене: если бы у вас была хорошая интуиция о том, что нужно построить, он будет выяснять то же самое, а затем вы можете обсудить детали.
Вполне возможно, что, узнав о своем домене, он предложит более простое или радикально другое решение на более высоком уровне, из-за которого ваша первая проблема исчезнет, или существующий инструмент, который вы можете легко использовать.
Если вы пытаетесь определить проект по созданию обогреваемых рулей, то час, разговаривающий с хорошим программистом, заставит его предложить перчатки.
У меня это случилось со мной: клиент был готов заплатить мне за что-то, и после 20-минутного чата я указал им на существующий инструмент с открытым исходным кодом, который решил свою проблему в общем случае. У них просто не было знаний или мышления, чтобы проанализировать их проблему до такой степени.
Самое главное в этом - это диалог: вам нужно поделиться своими знаниями с разработчиком и вместе работать над решением. Бросать краткое описание конструкции и спецификации на стену недостаточно, потому что вы не используете их возможности для решения этой проблемы.
