Какие спецификации, документы, анализ вы получаете от начальства при запуске проекта?

Question

В настоящее время я работаю в малом бизнесе (15-20 сотрудников, 5 программистов), где большинство проектов представляют собой пользовательские CMS и несколько продуктов для веб-приложений.

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

Мой вопрос к вам, ребята, которые могут работать в разных сферах бизнеса: как (огромная куча бумаги? Документы Word? Visios?) И какую информацию вы получаете от своих начальств, менеджеров, коллег по команде при запуске проект (много анализов, чертежей и т. д.)? Как много деталей вы получаете по этому поводу?

Надеюсь, мой вопрос достаточно ясен, спасибо.

Answer 1

Спецификации .. это смешно ... как насчет никогда: (.

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

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

Answer 2

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

Тогда, как и должен хороший консультант, я возвращаю рецензию заказчику, проверяю ее, получаю подпись и создаю ее, и они живут долго и счастливо! (нет, они не меняют свое мнение 100 раз)

Answer 3

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

Проекты, которые мы получаем, делятся на три основные категории (в зависимости от спецификаций):

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

2. Небольшие изменения. Как простое электронное письмо, объясняющее, что цвет фона устарел, или запрос на сортировку отчета по другому столбцу. Мы просто делаем это, как позволяет время.

3. Интеграция крупных компаний, когда нам поручено заставить наше программное обеспечение работать с таким крупным оборудованием, как Intuit (QuickBook) или FedEx (тарифы на доставку). Они часто имеют хорошо продуманную документацию и примеры кода. Мы получаем сотни страниц в документах Word или PDF. Проблема в том, что их спецификации неверны. Мы узнаем о неточностях, когда пытаемся проверить или сертифицировать нашу интеграцию. В этих случаях нам обычно требуется больше времени для сертификации, чем для первоначальной разработки процессов.

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

Answer 4

Может варьироваться в зависимости от того, к какой группе относится работа:

1. Запрос поддержки - Если изменение займет короткий промежуток времени и устраняет неисправность, существует эта группа. Это может быть так просто, как «Добавить Боба в список авторизованных пользователей для этой древней формы», где форма написана много лет назад, и кроме добавления и удаления пользователей, она не затрагивается из-за боязни взлома.

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

3. Проект - в этом случае обычно есть несколько документов Word и / или темы электронной почты, которые помогают сгладить требования с точки зрения объема, бюджета и времени. Это может занять месяцы, хотя есть что сказать, что нужно изменить прототип, а не создавать первоначальный прототип, чтобы определить, действительно ли выполнены требования или нет. Конечно, моему текущему проекту уже более года, у него еще есть несколько месяцев до графика, и у него уже есть преемник после его завершения, т.е. есть фаза II, которая будет идти после фазы I.

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

Answer 5

Наши менеджеры по продуктам и старшие инженеры готовят три документа по планированию для наших проектов программного обеспечения для управления данными.

1. Требования высокого уровня: от 1 до 3 предложений описания поддерживаемого аппаратного / программного обеспечения или конкретной функции для этого проекта. (10-15 страниц Excel-подобных сеток)

2. Технические детали: Инженерное выполнение каждого требования высокого уровня. До страницы для каждого, в зависимости от количества деталей. (30-40 страниц заполненных деталей)

3. Бизнес-соглашение: краткое изложение 1 и 2 с графиком проектирования и анализом продукта Mgmt. Все подписываются на это. (5 страниц анализа, 20 технических)

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

Answer 6

У меня в настоящее время есть полдюжины или около того спецификации каждые 60-80 страниц Один из них - 80 страниц без оглавления. Хорошие времена.

Answer 7

Нет - по крайней мере, не от руководства.

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