Открыть список
Как стать автором
Обновить

Комментарии 20

Ну и как уточняющие вопросы помогут глухому телефону?

Привет, Владимир. Для сложных и больших проектов, предполагающих высокие риски созданы стандарты PMBOK, когда необходима высокая формализация требований имеет смысл применять нормы ГОСТ. Когда речь заходит об Agile-методологии при опросе заказчика создают user story (по крайней мере в SCRUM, хотя можно применять для описания бизнес-требований к функциям в любой методологии, например в KANBAN). Бизнес аналитики, PDM и тимлиды разработки обычно выбирают удобные им критерии и методы опроса заказчика, которые иногда зависят от выбранного стека и особенностей конкретного проекта (общих требований к результату). Если не понятна логика процесса или функции — рисуют блок схемы и прикрепляют к story, делят story на таски, детализируют до фрагментов функции или процессы. Чтобы обобщить и декомпозировать можно наклепать майндмэп. На каждом этапе это всё можно согласовывать. Возникает вопрос, зачем предложенный метод при использовании описанных типов ТЗ и методологий разработки? На каком этапе в приведенных типах ТЗ он применим? И ещё, приведённый гипотетически пример с Маарыйкой не соответствует лично моему практическому опыту. Обычно на каждом из этапов ТЗ усложняется и конкретизируется, в результате чего становится более подробным, но иногда менее интуитивно понятным (и вот тут на мой взгляд методы практической психологии могут помочь). В вашем же случае оно теряет значимые факты и сокращается, что в реальности маловероятно. Возможно я чего-то недопонял. Поясните, плиз.

Описанная метамодель предназначена для того, чтобы не упускать важные детали именно в разговоре. Она не для письменного ТЗ по нормам ГОСТ. И пример иллюстрирует лишь эффект глухого телефона, а не кейс из жизни.
Понятно, спасибо за ответ. В крупных компаниях существуют корпоративные стандарты интервьюирования заказчиков, иногда даже утилиты пишут специальные, которые позволяют формализовать бизнес-требования. Сталкивались ли вы с такими стандартами, на сколько, по вашему они отличаются от метамодели, которую вы предложили? Можно ли вашу метамодель привязать к созданию story в SCRUM?
Цель применения метамодели — прийти от общих слов к более осязаемым, которые однозначно понимаются большинством. Так что лучше бы использовать при формулировании story и задач.
На счет стандартов интервьюирования, боюсь, не совсем понимаю о чем речь.
Методологии (такие как SCRUM) никак не конкурируют с метамоделью. Просто они про другое. Так что эти модели легко можно применять совместно.
Методология предполагает требования к описанию функций и требований к проекту, SCRUM например, к стори, иными словами формализацию бизнес-требований, в KANBAN к описанию тасков. Стандарты управления проектами также формализуют всё, что касается коммуникации в проекте. Следуя этим требованиям и стандартам, как показывается практика, легко получить предсказуемый результат.
Странно. Крутая тема. И так мало комментариев. От когда пишут как заменить «обои» на «рабочем столе» то их 100500.
Дело в том, что про это написано и переписано очень много материалов. В данном же случае есть некоторая некорректная вводная, которая не отражает реалий разработки и документального сопровождения разработки. По этой причине люди воздерживаются от комментов, задавать уточняющие вопросы в подобном случае долго, разбираться в том, что имел ввиду автор никто не хочет, это должно быть понятно из текста статьи, особенно если он посвящён созданию ТЗ).И да, я не припомню, чтобы на хабре писали посты о смене обоев на рабочем столе).
Спасибо за ответ. Подскажите, где почитать по теме. А то сам уже запутался в «3 соснах». Спасибо.
О чем конкретно? На Хабре много статей посвящено созданию ТЗ. Опишите проблему подробнее. Возможно, я смогу порекомендавать конкретный материал.
1. Как рассчитывать время на выполнение задачи (подзадачи)?
2. Как рассчитывать постоянную составляющую (в советское время называлось обще-заводские), если в фирме несколько проектов в одно время?
3. Как оценить время работы девелопера, в зависимости от сложности задачи?
4. Ну и элементарное, на что обратить ОСОБОЕ внимание, чтобы не упустить при расчете стоимости,
5. Какая классическая рентабельность на рынке в России и Европах?
6. Как рассчитывать сопутствующие расходы, косвенно связанные с проектом?
Буду признателен, если тыкнете носом в нужную сторону.

1. Как рассчитывать время на выполнение задачи (подзадачи)?
Если речь о SCRUM, то тимлид оценив пользовательские стори должен предположить сколько строчек кода уйдёт на реализацию каждой из них и таким образом оценить длительность спринта(короткой итерации в SCRUM), определив дедлайн в соответствии с количеством разработчиков которые трудятся в этом спринте. Если тимлид говорит, что на основании имеющихся данных не готов это сделать (с точностью до плюс минут 48 часов), значит сторис в спринте требуют большей формализации. Т.е нужно, чтобы бизнес-аналитик или при неимении такового менеджер проекта связался с заказчиком и попросил уточнений относительно работы функций. Иногда, если мы говорим о проектах со сложным пользовательским интерфейсом и интуитивно не понятными пользовательскими функциями перед оценкой нужно сделать прототип UX, в идеале функциональный прототип в Adobe XD. Если у функций продукта сложная логика, к некоторым стори (для достоверной оценки трудозатрат и времени реализации) имеет смысл нарисовать блок схемы, чтобы разработчик понимал логику. Психологии на этом этапе мало, много формализации и учета требований. Но это азы, которые должен знать любой менеджер проекта и бизнес-аналитик.
2. Как рассчитывать постоянную составляющую (в советское время называлось обще-заводские), если в фирме несколько проектов в одно время?
Это зависит от методологии в рамках которой реализуются проекты. Не понимая как вы работаете не возможно что-то рассчитать. Если я правильно вас понял.
3. Как оценить время работы девелопера, в зависимости от сложности задачи?
Этим занимается тимлид(руководитель разработки), исходя из бизнес-требований описанных в ТЗ он назначает сотрудника уровень которого соответствует сложности задачи и определяет дедлайн на реализацию функции или процесса. Чем выше формализация в описании и точнее определены бизнес-требования, тем меньше ошибок будет на этом этапе.
4. Ну и элементарное, на что обратить ОСОБОЕ внимание, чтобы не упустить при расчете стоимости,?
Это очень абстрактный вопрос. Всё сильно зависит от проекта, области и т.д. Обычно дьявол сидит в сложной логике, на первый взгляд простых функций. Для того, чтобы не наступить на мину в этом вопросе лучше составить функциональную блок-схему описывающую логику, если она вызывает вопросы.
5. Какая классическая рентабельность на рынке в России и Европах?
Вопрос слишком абстрактный. если мы об аутсорсинге, то для каждой компании это является коммерческой тайной, можно предполагать только.
6. Как рассчитывать сопутствующие расходы, косвенно связанные с проектом?
Тут многое будет зависеть от конкретного проекта. Не существует единого списка сопутствующих расходов. Опять же имеет значение какие виджы работ берет на себя компания, а какие поручает партнёрам, сторонним исполнителям, субподрядчикам и т.п. Отдельная статья — тестовые серверы, если они нужны, аудит, в банковских проектах и проектах с защитой данных и криптографией — тестирование на взлом, тут вариантов миллионы. Юридическое сопровождение.
Если компания продуктовая, то тут ещё сложнее.
Мне ещё майндмэппинг помогает с оценкой предполагаемого объема работ. Удобно декомпозировать задачи. Надеюсь чем-то помог.
Большое спасибо. Вы очень мне помогли.
Обращайтесь. Мой телеграм: @rgmdev
По-моему, эксперимент был неправильно поставлен.

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

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

Вообще-то в здесь по сути идет речь об «извлечении знаний из эксперта», и предлагаемые вопросы и обсуждения, безусловно, важны. Но жизнь всегда будет богаче ;-)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
2015
Местоположение
Россия
Сайт
maxilect.com
Численность
31–50 человек
Дата регистрации

Блог на Хабре