Проектирование и разработка в чем разница
проектирование и разработка
проектирование и разработка: Совокупность процессов, переводящих требования в установленные характеристики или нормативную и техническую документацию на продукцию, процесс или систему.
3.4.4 проектирование и разработка (design and development): Совокупность процессов (3.4.1), переводящих требования (3.1.2) в установленные характеристики (3.5.1)или спецификации (3.7.3)на продукцию (3.4.2), процесс (3.4.1)или систему (3.2.1).
2 Для обозначения объекта проектирования и разработки могут применяться определяющие слова (например, проектирование и разработка продукции или проектирование и разработка процесса).
Проектирование и разработка — совокупность процессов, переводящих требования в установленные характеристики или нормативную и техническую документацию на продукцию, процесс или систему.
3.4.4 проектирование и разработка (en design and development; fr conception et développement): Совокупность процессов (3.4.1), переводящих требования (3.1.2) в установленные характеристики (3.5.1) или нормативную и техническую документацию (3.7.3) на продукцию (3.4.2), процесс (3.4.1) или систему (3.2.1).
2 Для обозначения объекта проектирования и разработки могут применяться определяющие слова (например проектирование и разработка продукции или проектирование и разработка процесса).
3.4.4 проектирование и разработка (design and development): Совокупность процессов (3.4.1), переводящих требования (3.1.2) в установленные характеристики (3.5.1)или спецификации (3.7.3)на продукцию (3.4.2), процесс (3.4.1)или систему (3.2.1).
2 Для обозначения объекта проектирования и разработки могут применяться определяющие слова (например, проектирование и разработка продукции или проектирование и разработка процесса).
3.4 проектирование и разработка: Совокупность процессов, переводящих требования в установленные характеристики или нормативную и техническую документацию на продукцию, процесс или систему.
3.2.31 проектирование и разработка (design and development): Совокупность процессов, переводящих требования в установленные характеристики или нормативную и техническую документацию на продукцию, процесс или систему.
6.3 проектирование и разработка (design and development): Совокупность процессов (6.4), переводящих требования в установленные характеристики или в техническую документацию на продукцию (6.2), процесс или систему.
[ИСО 9000:2005, статья 3.4.4]
Полезное
Смотреть что такое «проектирование и разработка» в других словарях:
проектирование и разработка — Совокупность процессов, переводящих требования в установленные характеристики или спецификации на продукцию, процесс или систему. Примечания 1. Термины «проектирование» и «разработка» иногда используют как синонимы, а иногда… … Справочник технического переводчика
проектирование карты — Разработка проекта вновь создаваемой карты или модернизации существующей карты. [ГОСТ 21667 76] проектирование карты Технологический процесс в составе картосоставительского процесса, предшествующий составлению и оформлению карты, заключающийся в… … Справочник технического переводчика
проектирование одностадийное — Разработка проекта в одну стадию для несложных объектов строительства или объектов, имеющих аналоги [Терминологический словарь по строительству на 12 языках (ВНИИИС Госстроя СССР)] Тематики проектирование, документация EN single stage design work … Справочник технического переводчика
проектирование типовое — Разработка типовых проектов сооружений, зданий, конструкций и оборудования, предназначенных для многократного применения в строительстве [Терминологический словарь по строительству на 12 языках (ВНИИИС Госстроя СССР)] Тематики проектирование,… … Справочник технического переводчика
Проектирование Организационное — разработка программы действий по совершенствованию деятельности органов управления, условий труда. Словарь бизнес терминов. Академик.ру. 2001 … Словарь бизнес-терминов
проектирование — 3.21 проектирование (design): Все связанные виды инженерной деятельности, необходимые для разработки проекта трубопровода, включая как конструирование, так и подбор материалов и защиту от коррозии. Источник: ГОСТ Р 54382 2011: Нефтяная и газовая… … Словарь-справочник терминов нормативно-технической документации
Проектирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • … Википедия
Проектирование ПО — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ | Проектирование | Реализация | Тестирование | Внедрение | Сопровождение Модели / методы Agile | Cleanroom | Итеративная | Scrum | RUP | MSF | Спиральная | Во … Википедия
Разработка через тестирование — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Проектирование трубопроводов — (a. pipeline design; н. Planung der Rohrleitungen, Projektierung der Pipelines; ф. conception des tuyauteries, etude des conduites; и. elaboracion de proyectos de tuberis) разработка комплексной техн. документации (проекта), содержащей… … Геологическая энциклопедия
Проектирование и разработка
Очень часто проектирование и разработку в организациях выделяют как процесс. Для того чтобы он соответствовал положениям МС ИСО 9001:2000, при его выполнении следует выполнить специальные требования, изложенные в п. 7.3 МС ИСО 9001:2000. На рис. 5.18 в графическом виде показан процесс проектирования, а также порядок реализации требований МС ИСО 9001:2000 на различных этапах процесса проектирования и разработки. Данная деятельность может быть выделена как самостоятельный процесс, входящий в состав сети процессов организации. В зависимости от области деятельности, специфики и размеров организации процесс может быть выделен следующим образом:
• «Процесс проектирования и разработки продукции (услуги)» — обычное
название для промышленного предприятия; компании, разрабатывающей
новые виды продукции и/или услуг (программное обеспечение, сервис
ное обслуживание, туристические услуги и т.д.);
• «Процесс разработки технических условий (регламентов)» — применяет
ся для организаций, которые не разрабатывают новые продукты, работа
ют по лицензии на выпуск продукции и в соответствии с российским
законодательством разрабатывают и выпускают технические условия
(ТУ) или технические регламенты (ТР) на производимую продукцию. Не
выделяют как самостоятельный процесс для небольшого предприятия,
где разработка и оформление ТУ и/или ТР возложены на главного кон
структора (технолога).
346 В.В. Репин, В.Г. Елиферов. Процессный подход к управлению
Рис. 5.18. Перенос требований МС ИСО 9001:2000 на этапы процесса проектирования и разработки.
Глава 5 Описание бизнес-процессов при внедрении системы менеджмента качества 347
Принципиальное значение для объединения видов деятельности по разработке и проектированию в самостоятельный процесс имеют:
а) трудоемкость данных видов деятельности;
б) необходимость назначения владельца данного процесса для планирова
ния и организации его выполнения;
в) необходимость построения системы контроля за ходом процесса и управ
ления видами деятельности и ресурсами данного процесса.
Несмотря на то, что каждый отдельный проект или разработка выполняются на основе проектного управления, отдельные части проекта могут повторяться и выполняться на процессной основе.
При описании этого процесса следует принимать во внимание следующие соображения.
Соображение 1. Втексте МС ИСО 9001:2000 нет прямого указания на то, к проектированию и разработке какого продукта относятся требования п. 7.3, однако в МС ИСО 9000:2000 в п. 3.4.4 четко определено:
«3.4.4 Проектирование и разработка (design and development)— совокупность процессов, переводящих требования в конкретные характеристики продукции, процесса или системы, или в технические условия на них».
Таким образом, даже если организация не занимается разработкой продукции или процессов, но выпускает на продукцию свои ТУ, все равно эти действия подпадают под требования п. 7.3 МС ИСО 9001:2000. В России выпуск продукции в соответствии с ТУ (с 01.07.2003 г. — ТР, статья 2 Закона Российской Федерации «О техническом регулировании») собственной разработки стал распространенной практикой для большинства предприятий, производящих продукцию промышленного и потребительского назначения.
Соображение 2.Многообразие видов продукции и степень участия организации в проектировании и разработке продукции очень велика, поэтому в соответствии с разрешениями, приведенными в п. 1.2 МС ИСО 9001:2000, часть требований раздела 7 может быть изъята в связи с неприменимостью для данной организации.
Соображение 3.Схема, представленная на рис. 5.18, не является универсальной и исчерпывающей для описания процесса проектирования и разработки. Как любой другой процесс, он должен иметь:
• владельца (начальник конструкторского бюро, директор НИИ, главный
технолог или главный конструктор и т.д.);
• все необходимые ресурсы (квалифицированный и аттестованный персо
нал, оборудование, информация и программное обеспечение, среда и ин
фраструктура);
• показатели процесса (время на проект, трудозатраты, финансовые пока
затели стоимости проектирования и испытаний и т.д.) и продукта (ре
зультаты проектирования и разработки, технические характеристики раз-
348___________________________ В.В. Репин, В.Г. Елиферов. Процессный подход к управлению
работанных продуктов, степень их соответствия лучшим зарубежным образцам, технологичность в производстве и т.д.);
• поставщиков, потребителей и соисполнителей процесса проектирования и разработки (поставщики ресурсов — вспомогательные подразделения; поставщики входной информации — внешние потребители и заказчики, внутренние — отдел маркетинга и производственные участки; потребители — отдел маркетинга, если он инициировал разработку; производство, если оно будет использовать результаты проектирования и разработки продукта/технологии; внешний потребитель — который должен получить результат, превышающий его ожидания).
Соображение 4. Ворганизациях, работающих по проектному принципу (выполнение разовых, длительных, неповторяющихся проектов), каждый проект проходит через несколько подразделений и служб, и назначение владельца процесса проектирования не всегда целесообразно. В этом случае проектный заказ можно разбить на ряд последовательных действий, которые повторяются при исполнении различных проектов. При таком разбиении появляется возможность оценить экономическую эффективность выполнения отдельных частей проекта, так как они циклически повторяются в похожих условиях в пределах одного подразделения и юрисдикции одного владельца. В этом случае часто назначается менеджер проекта, в обязанность которого входит контроль за выполнением сроков и полноты этапов проекта. За общий ход проекта несет ответственность один из руководителей верхнего уровня. Так, при строительстве электростанции или другого крупного объекта, кроме дирекции объекта, назначается дирекция строительства, которая отвечает за своевременное и полноценное завершение проекта.
Соображение 5. Ворганизациях, построенных по принципу «НИИ— завод» («КБ — завод»), которые сами разрабатывают новые образцы продукции (услуг), разработка и проектирование ведутся непрерывно. В этом случае управление проектированием и разработкой целесообразно построить на процессной основе. Легко определяются владелец процесса (главный конструктор/технолог), а также показатели выполнения плана-графика разработки, бюджеты проектов и результаты приемки проектов.
Закупки
Процесс закупок
Закупки часто выделяют в отдельный процесс. Различные способы выделения «Процесса закупок» рассмотрены в примерах 4.1 и 4.2 главы 4. Один из вариантов построения алгоритма выполнения «Процесса закупок» приведен в Приложении 9. Часто встречается ситуация, когда за закупку материалов несет ответственность начальник Отдела закупок, входной контроль закуп-
Глава 5 Описание бизнес-процессов при внедрении системы менеджмента качества 349
ленных материалов проводит ОТК или Лаборатория входного контроля (ЛВК), рекламационная работа по материалу, забракованному на входном контроле, возложена на Отдел закупок и юристов. В этом случае целесообразно выходом «Процесса закупок» считать факт приемки материала сотрудниками ОТК (ЛВК), который в этой ситуации выступает как соисполнитель «Процесса закупок». Зона ответственности владельца «Процесса закупок» (начальника Отдела снабжения) распространяется на закупленные продукты до момента признания их годными к использованию в технологии производства конечного продукта. Если результаты входного контроля показали, что продукт имеет отклонения от установленных требований, то владелец «Процесса закупок» отвечает за принятие решения по продукции, отклоненной от использования в производстве (включая рекламационную работу с поставщиком), и за решение о поставке новой партии продукции взамен забракованной.
Вид и объем входного контроля, применяемого для каждого материала и проводимого в организации, зависят от следующего:
• влияние данного входящего продукта, материала, комплектующего изде
лия и т.д. на качество конечной продукции;
• соотношение уровня качества входящего продукта и целесообразность
затрат на введение определенного вида контроля для данного материала;
• объем и достоверность выходного контроля данного продукта у поставщика.
Объем и вид входного контроля, применяемого для каждого материала, устанавливаются в соответствии с требованиями технических условий (государственных и отраслевых стандартов) на продукцию. Ужесточение норм входного контроля допускается по согласованию с поставщиком и обычно вносится в договор на поставку в раздел «Качество». Место проведения входного контроля выбирается по согласованию между поставщиком и потребителем. Например, тестирование и инсталляция закупленного программного обеспечения может производиться только у потребителя. С другой стороны, на промышленных предприятиях желательно относить затраты на обеспечение качества входящей продукции на поставщика.
Для проведения оценки поставщиков и выбора наиболее пригодного используется таблица оценки поставщиков (см. Приложение 10). Организация может дополнить или изменить предлагаемый перечень характеристик поставщика. Заполнение такой таблицы можно вести по балльной шкале. В данной таблице предусмотрена трехбалльная шкала оценки поставщиков. Сюда же можно внести данные о рекламациях продукции по каждому поставщику. Часто бывает целесообразно в дополнение к таблице составить инструкцию для менеджера по закупкам о том, как заполнять данную таблицу и как ею пользоваться для принятия решения о возможности закупки продукции у нового поставщика.
350 В.В. Репин, В.Г. Елиферов. Процессный подход к управлению
7.4.2. Информация о закупках
Практически во всех текстах переводов МС ИСО 9001:2000 на русский язык отсутствует ссылка на то, что требования данного пункта относятся к организации-поставщику. То есть предъявляемые требования к продукции, оборудованию, процессам, персоналу и системе менеджмента качества организации — поставщика продукции (услуг, материалов, полуфабрикатов и т.д.), если такие предъявляются, должны быть внесены в контракты и договоры на поставку. На практике это обычно реализуется внесением в договор на поставку ссылки на технические требования (спецификацию) продукции. Приоритетом на установление таких требований пользуются:
• службы главного конструктора и главного технолога;
• производственные конструкторские и технологические бюро;
• конечные потребители (заказчики) продукции.
При написании Руководства по качеству вносить все эти данные в документ нет необходимости, так как их состав и требования могут меняться чаще, чем оно пересматривается. Обычно эти данные вносят в один из следующих документов:
• Программа обеспечения качества;
• Список материалов, разрешенных к применению;
• Список материалов, подлежащих входному контролю.
Часто возникает вопрос: Что делать, если поставщик программного обеспечения использует в своих разработках нелицензионные версии программных продуктов?
Проблемы с использованием в своих разработках нелицензионного программного обеспечения организации — производители IT-продукции решают в каждом конкретном случае. При этом приходится оценивать риски последствий отказов программных продуктов в связи с использованием программных модулей сомнительного происхождения.
7.4.3. Проверка закупленной продукции
Входной контроль закупленной продукции, необходимый для обеспечения уверенности в том, что закупаемая продукция соответствует установленным закупочным требованиям, проводит ОТК (ЛВК) в соответствии с требованиями и процедурами, установленными в Программе качества (Программе обеспечения качества). В рабочих документах, регламентирующих проведение операций входного контроля, должны быть установлены:
• правила отбора проб (выборок);
• план и объем контроля;
• утвержденные методики контроля и контролируемые параметры продукции;
Глава 5 Описание бизнес-процессов при внедрении системы менеджмента качества 351
• 
однозначный порядок принятия решения о соответствии или несоответ
ствии проверяемой партии установленным требованиям (критериям);
• порядок оформления претензии поставщику в случае выявления несоот
ветствующей продукции;
• порядок идентификации продукции, исключающий непреднамеренное
использование несоответствующей продукции;
• при необходимости дальнейшие действия и система оповещения о при
годности или непригодности продукции к применению.
Все эти процедуры являются стандартными для документального оформления любой контрольной операции проверки соответствия продукции установленным требованиям. Последовательность их изложена в § 4.3.1 главы 4 и на рис. 4.10.
Кроме того, обычно приходится учитывать требования принятия решения по конечной продукции, выпущенной с использованием входящих материалов с отклонениями от установленных норм, в случае позднего обнаружения отклонения.
Проектирование и разработка
Под понятием проектирование и разработка в соответствии с ГОСТ Р ИСО 9000-2001 принимается – совокупность процессов, переводящих требования в установленные характеристики или нормативную и техническую документацию на продукцию, процесс или систему.
Из определения понятия проектирование и разработка следует, что:
понятия проектирование и разработка в соответствии с ГОСТ Р ИСО 9000-2001 не разделены, таким образом словом проект можно принимать, как русском, так и в английском его значении;
поскольку сам процесс есть совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы, то проектирование само представляет собой процесс.
Отдельные требования, содержащиеся в Разделе 7 ГОСТ Р ИСО 9001-2001 в отличие от остальных разделов стандарта могут быть согласно п.1.2. обосновано исключены. В соответствии с этим весь подраздел 7.3 может быть исключен, если организация не выполняет проектных работ.
ГОСТ Р ИСО 9001-2001 устанавливает требования не к методам проектирования, которые установлены соответствующими нормативными документами разных рангов (СНиП, СТО и т.п.), а к организации проектных работ и связанных с ними видам деятельности.
В подразделе 7.3ГОСТ Р ИСО 9001-2001 установленытребования к отдельным переделамтехнологического процессапроектирования:
планирование проектирования,
входные данные для проектирования;
выходные данные проектирования,
анализ проекта,
верификация (проверка) проекта,
валидация (утверждение)проекта,
управление изменениями проекта.
При планировании (п.7.3.1)
В ходе планированияорганизация должна:
а) установить стадии проектирования,
б) определить необходимостьпроведения анализа, верификации и валидации на стадиях проектирования;
в) установить распределение ответственности и полномочий среди участниковпроектирования;
разработать систему управления группами, участвующими в проектировании;
планирование должно анализироваться и актуализироваться в процессе проектирования результаты промежуточных работ(если в этом есть необходимость).
Требования пункта 7.3.1 не отличаютсяот требований установленных в нормативных документах России.
Разработка проекта vs разработка продукта — в чем разница
Есть проекты, а есть продукты. Причем оба термина применимы далеко не только к айтишной сфере. Батон и бублик — продукты, а запуск на хлебокомбинате новой линии по выпечке капкейков — проект.
Но если бы всё было так же просто, как хлебушек, то не было бы статьи. А она есть. Как еще можно отличить продукт от проекта:
Ну то есть в целом понятно.
Если говорить про айтишные дела, то когда у тебя есть сервис, который ты бесконечно улучшаешь, меняешь, измеряешь реакцию целевых пользователей, снова меняешь, ищешь под него инвестиции, кусаешь локти, если что-то идет не так, закладываешь свой УАЗ в ломбард ради новой фичи — у тебя стартап продукт. И у тебя, вероятно, продуктовая команда.
Когда у тебя есть краткосрочная задача запилить что-то по определенным требованиям (сайт, логотип, рекламную кампанию и т.д.) забрать деньги и отдать то, что получилось, в руки заказчика — у тебя проект. Вернее, проекты — потому что один закончился, начался второй, конвейер крутится, профиты мутятся.
Казалось бы, разница невелика — проекты, продукты, один хрен те же самые специалисты сидят и делают примерно одно и то же. Так же за ними присматривает менеджер. Также бюджет берется из кармана владельца бизнеса. Но нет, всё работает по-разному.
Разберем различия с точки зрения владельца-заказчика, команды исполнителей и руководителя.
Работа над проектом и продуктом: в шкуре владельца
Проектная разработка
Хотя адепты гибких методологий и называют заказчика сайта Product Owner’ом — на деле же он таких функций не выполняет. Банкет оплачивает, иногда вторгается в уютный мирок заказной разработки со своей картиной мира и правочками. Но не больше.
Вообще аутсорсинговая природа проекта формирует отношение владельца ко всему процессу. Команду он не хантит по человеку в месяц, никого не собеседует (и своего эйчара не напрягает). У него не болит голова насчет того, что с этими людьми делать дальше, когда работа закончится. Он не парится о мотивации или поиске компетентного менеджера на проект. Не рассчитывает окупаемость, не планирует бюджет.
Вместо этого он поступает просто: берет рейтинг самых-самых, выбирает из него кусок с подъемным для себя бюджетом, из него выбирает подрядчика, который больше понравился.
И дальше уже пошло-поехало: ТЗ, презентации, правочки. Стоп, снято, в продакшен.
Нет, само собой, бывают и совсем другие истории — когда заказчик компетентный в разработке ИТ-проектов, у него сильная команда на своей стороне, маркетологи, техдиректор, проект-менеджер, дизайнеры, контентщики. А на аутсорс он пошел просто потому, что своих ресурсов не хватило (или не хватило специализации).
Еще случай «другой истории» — когда у бизнеса есть доверенное агентство, взявшее на себя весь диджитал. Разные возникающие проекты агентство отдает аутсорс-продакшену.
В обоих случаях уровень работы приближается к продуктовому — тоже KPI, внятные постановки с самого начала, меньше неопределенности. Но это, скорее, исключение из правил, как вы поняли.
Продуктовая разработка
Здесь всё иначе. Продукт, то есть программный продукт — это и есть конечная цель для владельца бизнеса. Вернее, бесконечная — потому что нельзя просто так взять и выложить программный продукт, а потом забить на его улучшения.
Теперь о том, как себя чувствует команда там и там.
Продуктовая команда и команда «на потоке»
Проектная разработка
Причем в процессе такой яростной гонки один из гребцов встает посреди лодки и говорит: «ребята, меня позвали вон на тот круизный лайнер, до свидания!». После чего включает свой реактивный ранец и улетает в голубую даль.
Работа команды, делающей проекты на потоке — это очень много стресса, переключений между задачами, подгорающий фитилек дедлайна и. чемодан опыта. Так что можно сказать, что потоковая разработка — для молодых и энергичных, здесь как нельзя быстрее можно научиться всему. Такой непрекращающийся интенсив длиною в несколько лет.
В продуктовой команде всё немного по-другому.
Продуктовая разработка
Программисты, которые ушли из студии и устроились в продукт — как правило, говорят о том, что там спокойнее. «Бесконечный» характер работы и отсутствие того самого подгорающего фитилька (и плеяды новых проектов на очереди) делают рабочий темп медленнее и вдумчивее.
У потоковой разработки в фокусе сроки — для студии их очень нежелательно сдвигать вперед (да и назад тоже). При плотной загрузке любой сдвиг идет в ущерб остальным проектам. Если при этом сроки растягиваются — то студия упускает прибыль.
В продуктовой разработке сроки важны, но не критичны. Здесь придерживаются философии: если сдвигаем — значит, совершенствуем, а значит, создаем потенциально более успешный продукт.
Ну это утрированно, но в целом так.
В продукте сильнее бизнес-составляющая. Собственно, та система координат, в которой работает вся команда, от продакт-директора до стажера — это целевые пользователи, конверсии, маркетинговые исследования и так далее. Просто так собраться кучкой и решить «а давайте следующий сайт запилим на Реакте!» — не получится. Маркетологи скажут, на чем, почему и зачем вы будете делать следующий сайт.
Сложно сказать, где команде работается лучше. Потоковая разработка — это отличное место для прокачки и развития «по горизонтали». Продуктовая — для углубления в какую-то одну тему. Вряд ли вы встретите человека, который бы хотел вернуться в потоковую разработку после продуктовой — как ни крути, а в продукте спокойнее (правда, если это типичный стартап, то «спокойствие» будет выражаться во впахивании по 12 часов в сутки).
Теперь о менеджменте всего этого.
Менеджер продукта и менеджер проекта — в чем разница
Проектная разработка
Менеджер проекта — это «свой парень». То есть, конечно, он немного из другой касты, но команда понимает: менеджер их защитит от неадекватных правок и нервотрепки.
С точки зрения экспертности проект-менеджера — он выступает для заказчика «консультантом по технологиям», дает экспертное мнение именно с точки зрения работы над проектом (а никак не с точки зрения бизнеса, здесь любая студия целиком полагается на экспертизу заказчика).
В чем заключаются главные функции проект-менеджера: обеспечить равномерную нагрузку на ресурсы, не промотать сроки, проконтролировать результат и продать готовую работу заказчику.
Продуктовая разработка
Вроде бы это тот же менеджер, вид сбоку, но нет. Главное отличие — продакт-менеджер является представителем бизнеса (умное слово: стейкхолдером).
На проектной разработке главным источником угрозы был заказчик — со всеми этими «я вам правочек принес», внезапными новыми идеями и поездками в отпуск. Поэтому менеджер был таким «фильтром», смягчающим внешнее воздействие на команду, защитником.
На продукте внешней угрозы нет — все работают над одним большим делом. Следовательно менеджер для команды сам становится источником угрозы. Для них он — как номенклатурный работник для простых работяг.
Соответственно, если менеджер переходит из потоковой разработки в продуктовую, его главная боль — научиться жить с тем, что он теперь еще в большей степени другая каста, нежели был раньше.
Что еще стоит добавить. Все умные методологии и роли, которые в них есть — изначально разрабатывались для продуктовых команд. Где реально делать ежедневные стендапы со всей командой и владельцем продукта. Где продакт-овнер — роль настоящая, а не номинальная. Где скрам — так скрам. Всё-таки на заказной разработке мало когда нужны эти самые поэтапные запуски, тестирование гипотез и прочая. Наше дело простое.
Применение всего этого опыта на заказной разработке — допустимо, иногда полезно, но не всегда обязательно.
Ну всё вроде бы
Понятно, что всех аспектов одной маленькой статьей не охватить, но мы хотя бы попытались. Есть ли третий путь, что-то между потоковым «клепанием» проектов одного за другим и усердным бдением над продуктом? Да, есть — но об этом расскажем потом.
Кстати, можно подписаться на наши пуши (вон там снизу справа колокольчик) — тогда свежие статейки будут поступать вам сразу по готовности.