Comments 20
Ну и как уточняющие вопросы помогут глухому телефону?
Привет, Владимир. Для сложных и больших проектов, предполагающих высокие риски созданы стандарты PMBOK, когда необходима высокая формализация требований имеет смысл применять нормы ГОСТ. Когда речь заходит об Agile-методологии при опросе заказчика создают user story (по крайней мере в SCRUM, хотя можно применять для описания бизнес-требований к функциям в любой методологии, например в KANBAN). Бизнес аналитики, PDM и тимлиды разработки обычно выбирают удобные им критерии и методы опроса заказчика, которые иногда зависят от выбранного стека и особенностей конкретного проекта (общих требований к результату). Если не понятна логика процесса или функции — рисуют блок схемы и прикрепляют к story, делят story на таски, детализируют до фрагментов функции или процессы. Чтобы обобщить и декомпозировать можно наклепать майндмэп. На каждом этапе это всё можно согласовывать. Возникает вопрос, зачем предложенный метод при использовании описанных типов ТЗ и методологий разработки? На каком этапе в приведенных типах ТЗ он применим? И ещё, приведённый гипотетически пример с Маарыйкой не соответствует лично моему практическому опыту. Обычно на каждом из этапов ТЗ усложняется и конкретизируется, в результате чего становится более подробным, но иногда менее интуитивно понятным (и вот тут на мой взгляд методы практической психологии могут помочь). В вашем же случае оно теряет значимые факты и сокращается, что в реальности маловероятно. Возможно я чего-то недопонял. Поясните, плиз.
Описанная метамодель предназначена для того, чтобы не упускать важные детали именно в разговоре. Она не для письменного ТЗ по нормам ГОСТ. И пример иллюстрирует лишь эффект глухого телефона, а не кейс из жизни.
Понятно, спасибо за ответ. В крупных компаниях существуют корпоративные стандарты интервьюирования заказчиков, иногда даже утилиты пишут специальные, которые позволяют формализовать бизнес-требования. Сталкивались ли вы с такими стандартами, на сколько, по вашему они отличаются от метамодели, которую вы предложили? Можно ли вашу метамодель привязать к созданию story в SCRUM?
Цель применения метамодели — прийти от общих слов к более осязаемым, которые однозначно понимаются большинством. Так что лучше бы использовать при формулировании story и задач.
На счет стандартов интервьюирования, боюсь, не совсем понимаю о чем речь.
Методологии (такие как SCRUM) никак не конкурируют с метамоделью. Просто они про другое. Так что эти модели легко можно применять совместно.
На счет стандартов интервьюирования, боюсь, не совсем понимаю о чем речь.
Методологии (такие как SCRUM) никак не конкурируют с метамоделью. Просто они про другое. Так что эти модели легко можно применять совместно.
Методология предполагает требования к описанию функций и требований к проекту, SCRUM например, к стори, иными словами формализацию бизнес-требований, в KANBAN к описанию тасков. Стандарты управления проектами также формализуют всё, что касается коммуникации в проекте. Следуя этим требованиям и стандартам, как показывается практика, легко получить предсказуемый результат.
Странно. Крутая тема. И так мало комментариев. От когда пишут как заменить «обои» на «рабочем столе» то их 100500.
Дело в том, что про это написано и переписано очень много материалов. В данном же случае есть некоторая некорректная вводная, которая не отражает реалий разработки и документального сопровождения разработки. По этой причине люди воздерживаются от комментов, задавать уточняющие вопросы в подобном случае долго, разбираться в том, что имел ввиду автор никто не хочет, это должно быть понятно из текста статьи, особенно если он посвящён созданию ТЗ).И да, я не припомню, чтобы на хабре писали посты о смене обоев на рабочем столе).
Спасибо за ответ. Подскажите, где почитать по теме. А то сам уже запутался в «3 соснах». Спасибо.
О чем конкретно? На Хабре много статей посвящено созданию ТЗ. Опишите проблему подробнее. Возможно, я смогу порекомендавать конкретный материал.
1. Как рассчитывать время на выполнение задачи (подзадачи)?
2. Как рассчитывать постоянную составляющую (в советское время называлось обще-заводские), если в фирме несколько проектов в одно время?
3. Как оценить время работы девелопера, в зависимости от сложности задачи?
4. Ну и элементарное, на что обратить ОСОБОЕ внимание, чтобы не упустить при расчете стоимости,
5. Какая классическая рентабельность на рынке в России и Европах?
6. Как рассчитывать сопутствующие расходы, косвенно связанные с проектом?
Буду признателен, если тыкнете носом в нужную сторону.
2. Как рассчитывать постоянную составляющую (в советское время называлось обще-заводские), если в фирме несколько проектов в одно время?
3. Как оценить время работы девелопера, в зависимости от сложности задачи?
4. Ну и элементарное, на что обратить ОСОБОЕ внимание, чтобы не упустить при расчете стоимости,
5. Какая классическая рентабельность на рынке в России и Европах?
6. Как рассчитывать сопутствующие расходы, косвенно связанные с проектом?
Буду признателен, если тыкнете носом в нужную сторону.
1. Как рассчитывать время на выполнение задачи (подзадачи)?
Если речь о SCRUM, то тимлид оценив пользовательские стори должен предположить сколько строчек кода уйдёт на реализацию каждой из них и таким образом оценить длительность спринта(короткой итерации в SCRUM), определив дедлайн в соответствии с количеством разработчиков которые трудятся в этом спринте. Если тимлид говорит, что на основании имеющихся данных не готов это сделать (с точностью до плюс минут 48 часов), значит сторис в спринте требуют большей формализации. Т.е нужно, чтобы бизнес-аналитик или при неимении такового менеджер проекта связался с заказчиком и попросил уточнений относительно работы функций. Иногда, если мы говорим о проектах со сложным пользовательским интерфейсом и интуитивно не понятными пользовательскими функциями перед оценкой нужно сделать прототип UX, в идеале функциональный прототип в Adobe XD. Если у функций продукта сложная логика, к некоторым стори (для достоверной оценки трудозатрат и времени реализации) имеет смысл нарисовать блок схемы, чтобы разработчик понимал логику. Психологии на этом этапе мало, много формализации и учета требований. Но это азы, которые должен знать любой менеджер проекта и бизнес-аналитик.
Если речь о SCRUM, то тимлид оценив пользовательские стори должен предположить сколько строчек кода уйдёт на реализацию каждой из них и таким образом оценить длительность спринта(короткой итерации в SCRUM), определив дедлайн в соответствии с количеством разработчиков которые трудятся в этом спринте. Если тимлид говорит, что на основании имеющихся данных не готов это сделать (с точностью до плюс минут 48 часов), значит сторис в спринте требуют большей формализации. Т.е нужно, чтобы бизнес-аналитик или при неимении такового менеджер проекта связался с заказчиком и попросил уточнений относительно работы функций. Иногда, если мы говорим о проектах со сложным пользовательским интерфейсом и интуитивно не понятными пользовательскими функциями перед оценкой нужно сделать прототип UX, в идеале функциональный прототип в Adobe XD. Если у функций продукта сложная логика, к некоторым стори (для достоверной оценки трудозатрат и времени реализации) имеет смысл нарисовать блок схемы, чтобы разработчик понимал логику. Психологии на этом этапе мало, много формализации и учета требований. Но это азы, которые должен знать любой менеджер проекта и бизнес-аналитик.
2. Как рассчитывать постоянную составляющую (в советское время называлось обще-заводские), если в фирме несколько проектов в одно время?
Это зависит от методологии в рамках которой реализуются проекты. Не понимая как вы работаете не возможно что-то рассчитать. Если я правильно вас понял.
Это зависит от методологии в рамках которой реализуются проекты. Не понимая как вы работаете не возможно что-то рассчитать. Если я правильно вас понял.
3. Как оценить время работы девелопера, в зависимости от сложности задачи?
Этим занимается тимлид(руководитель разработки), исходя из бизнес-требований описанных в ТЗ он назначает сотрудника уровень которого соответствует сложности задачи и определяет дедлайн на реализацию функции или процесса. Чем выше формализация в описании и точнее определены бизнес-требования, тем меньше ошибок будет на этом этапе.
Этим занимается тимлид(руководитель разработки), исходя из бизнес-требований описанных в ТЗ он назначает сотрудника уровень которого соответствует сложности задачи и определяет дедлайн на реализацию функции или процесса. Чем выше формализация в описании и точнее определены бизнес-требования, тем меньше ошибок будет на этом этапе.
4. Ну и элементарное, на что обратить ОСОБОЕ внимание, чтобы не упустить при расчете стоимости,?
Это очень абстрактный вопрос. Всё сильно зависит от проекта, области и т.д. Обычно дьявол сидит в сложной логике, на первый взгляд простых функций. Для того, чтобы не наступить на мину в этом вопросе лучше составить функциональную блок-схему описывающую логику, если она вызывает вопросы.
Это очень абстрактный вопрос. Всё сильно зависит от проекта, области и т.д. Обычно дьявол сидит в сложной логике, на первый взгляд простых функций. Для того, чтобы не наступить на мину в этом вопросе лучше составить функциональную блок-схему описывающую логику, если она вызывает вопросы.
5. Какая классическая рентабельность на рынке в России и Европах?
Вопрос слишком абстрактный. если мы об аутсорсинге, то для каждой компании это является коммерческой тайной, можно предполагать только.
6. Как рассчитывать сопутствующие расходы, косвенно связанные с проектом?
Тут многое будет зависеть от конкретного проекта. Не существует единого списка сопутствующих расходов. Опять же имеет значение какие виджы работ берет на себя компания, а какие поручает партнёрам, сторонним исполнителям, субподрядчикам и т.п. Отдельная статья — тестовые серверы, если они нужны, аудит, в банковских проектах и проектах с защитой данных и криптографией — тестирование на взлом, тут вариантов миллионы. Юридическое сопровождение.
Если компания продуктовая, то тут ещё сложнее.
Вопрос слишком абстрактный. если мы об аутсорсинге, то для каждой компании это является коммерческой тайной, можно предполагать только.
6. Как рассчитывать сопутствующие расходы, косвенно связанные с проектом?
Тут многое будет зависеть от конкретного проекта. Не существует единого списка сопутствующих расходов. Опять же имеет значение какие виджы работ берет на себя компания, а какие поручает партнёрам, сторонним исполнителям, субподрядчикам и т.п. Отдельная статья — тестовые серверы, если они нужны, аудит, в банковских проектах и проектах с защитой данных и криптографией — тестирование на взлом, тут вариантов миллионы. Юридическое сопровождение.
Если компания продуктовая, то тут ещё сложнее.
Мне ещё майндмэппинг помогает с оценкой предполагаемого объема работ. Удобно декомпозировать задачи. Надеюсь чем-то помог.
По-моему, эксперимент был неправильно поставлен.
Вообще-то в техническом задании изначально ставится акцент на формальном описании и точности формулировок. Здесь же исходное описание составлено в форме цветастой былины, что сильно затрудняет выделение существенных технических признаков и деталей. Обычно для приведения такого текста к удобоваримому виду требуется вдумчиво посидеть над текстом и выбросить оттуда всю литературщину, а тут первого слушателя заставили все делать в уме и на лету.
Ну и как информация о том, что «пришелец откроет нам изобильный мир, где мы будем пребывать в счастье и радости, и непрекращающемся наслаждении» относится к техническому заданию?? Неудивительно, что она была немедленно выброшена.
Вообще-то в здесь по сути идет речь об «извлечении знаний из эксперта», и предлагаемые вопросы и обсуждения, безусловно, важны. Но жизнь всегда будет богаче ;-)
Вообще-то в техническом задании изначально ставится акцент на формальном описании и точности формулировок. Здесь же исходное описание составлено в форме цветастой былины, что сильно затрудняет выделение существенных технических признаков и деталей. Обычно для приведения такого текста к удобоваримому виду требуется вдумчиво посидеть над текстом и выбросить оттуда всю литературщину, а тут первого слушателя заставили все делать в уме и на лету.
Ну и как информация о том, что «пришелец откроет нам изобильный мир, где мы будем пребывать в счастье и радости, и непрекращающемся наслаждении» относится к техническому заданию?? Неудивительно, что она была немедленно выброшена.
Вообще-то в здесь по сути идет речь об «извлечении знаний из эксперта», и предлагаемые вопросы и обсуждения, безусловно, важны. Но жизнь всегда будет богаче ;-)
Sign up to leave a comment.
Уточняем детали проекта методами практической психологии