Комментарии 39
Ээээ, простите, а какая связь между «менеджером проектов» и ТЗ? Написание ТЗ — работа для аналитика, а не для РП/PM.
Возможно в вашей компании иначе, но в моей написанием технического задания занимается менеджер проекта.
В компании, где я работаю (и во всех компаниях, где я работал), менеджер проекта занимался управлением проектом. А ТЗ писали аналитики.
Если вы не понимаете этого разделения — значит, вас плохо учат.
Если вы не понимаете этого разделения — значит, вас плохо учат.
однако это не исключает то, что есть компании, работающие по другому принципу
Есть люди, стоящие на головах, и люди, ходящие на руках. Но это не повод. Есть некое принятое и устоявшееся разделение ролей.
Сударь, не будьте так категоричны. В маленьких студиях, а также в стартапах, часто один человек совмещает несколько ролей. Я знаю такие компании, где ПМ рисует прототипы, составляет ТЗ, а также тестирует функционал.
Автор топика не говорил, что не понимает разделения. Просто так в их компании заведено, а он не имеет права голоса, потому что находится на «рабской стажировке». Возможно когда-нибудь, а может и комментарии к этой статье помогут, в компании автора все поменяется и придет к устоявшийся модели разделения ролей.
Автор топика не говорил, что не понимает разделения. Просто так в их компании заведено, а он не имеет права голоса, потому что находится на «рабской стажировке». Возможно когда-нибудь, а может и комментарии к этой статье помогут, в компании автора все поменяется и придет к устоявшийся модели разделения ролей.
Стоп-стоп. Совмещение ролей — это как раз нормально, просто надо отдавать себе отчет в том, какую роль в какой момент времени ты выполняешь. Интересы ролей конфликтуют обычно.
Если заглянуть, например, в PMBoK, в нем есть целый раздел, посвященный scope management. И в нем очень подробно описано, как собирать требования. Авторы явно намекают, что зачастую сбор и описание требований — работа PM. Так что я не был бы так категоричен.
Управление скоупом проекта — действительно дело PM, и для этого нужна оценка требований. Но requirement elicitation — это удел аналитика. Не говоря уже о том, что сбор требований и написание ТЗ — не одно и то же.
Не могли бы вы пояснить, в чем разница? Интуитивно я, наверное, понимаю, но с трудом могу себе представить, как можно собрать требования, не описав их. На выходе процесса Collect Requirements из PMBoK, кстати, стоят Requirements Documentation и Requirements Traceability Matrix.
Я довольно часто сталкивался с тем, что на небольших проектах, особенно, когда не нужно писать многотомные ТЗ, а достаточно краткого описания требований, этим описанием занимается PM. И не стал бы так категорично говорить, что написание требований — задача исключительно аналитика.
Я довольно часто сталкивался с тем, что на небольших проектах, особенно, когда не нужно писать многотомные ТЗ, а достаточно краткого описания требований, этим описанием занимается PM. И не стал бы так категорично говорить, что написание требований — задача исключительно аналитика.
Все зависит от методологии, но в общем случае сбор требований (первичный) — это фиксация пожеланий заказчика в части общего объема функциональности будущей системы. А ТЗ — это подробное описание требований, основанное не только на словах заказчика, формализованное и непротиворечивое. Вопрос банально в детализации.
Встречный вопрос: я конкретный PMBoK не читал, но разве он утверждает, что процесс Collect Requirements выполняется именно PM-ом? Вот что показывает первое же гугление: «This process describes the responsibilities of the business analyst—if one is part of the team. This alone is an indicator that specialized knowledge and experience is especially useful for performing this particular process.»
Встречный вопрос: я конкретный PMBoK не читал, но разве он утверждает, что процесс Collect Requirements выполняется именно PM-ом? Вот что показывает первое же гугление: «This process describes the responsibilities of the business analyst—if one is part of the team. This alone is an indicator that specialized knowledge and experience is especially useful for performing this particular process.»
Нет, PMBoK не говорит, кто конкретно должен выполнять тот или иной процесс. Но по косвенным признакам (очень подробное описание, не BABoK, конечно, но все же) можно судить, что авторы хотели сказать, что менеджер проектов как минимум не должен говорить «а, в команде нет и не предвидится аналитика, ну значит и на требования можно забить».
Ненавижу я эти ТЗ, как-то заставили меня (тогда еще программиста фрилансера) и менеджера писать ТЗ на небольшой гос.проект, дали номер заказчика и дедлайн сутки. Худшие 24 часа в моей жизни.
В 80% ИТ-проектов выделение аналитика в отдельную позицию нерентабельно.
Среди малых проектов таких проектов 98%.
Среди средних — 30%
Среди крупных — практически 0.
Но за счёт большого количества мелких проектов они побеждают в статистике.
Среди малых проектов таких проектов 98%.
Среди средних — 30%
Среди крупных — практически 0.
Но за счёт большого количества мелких проектов они побеждают в статистике.
Извините, я возможно не совсем понял, но в чем ценность вашей статьи для аудитории?
Когда человек работает — он учится и улучшает свои навыки :D
Просто делюсь опытом. Может, кто-то так же как я впервые встретился с написанием технического задания, не знает с чего начать и сможет подчеркнуть для себя интересные мысли.
Может, стоит прочитать профильной литературы? Вигерса, например?
Верно) это стало вторым шагом.
Но некоторые студенты- люди ленивые, и пока не столкнуться с проблемой лоб ко лбу читать дополнительную литературу они не будут.
Но некоторые студенты- люди ленивые, и пока не столкнуться с проблемой лоб ко лбу читать дополнительную литературу они не будут.
А должно быть первым. Более того, если вас этому учили, то с литературой вы должны были ознакомиться в процессе обучения.
В теории да. Только так и должно. По 10 предметам 5-6 рекомендованных книг и это за 6 месяцев. Но кто это читает?
Я не знаю, что из того что мне преподают мне действительно будет необходимо. Именно по-этому я пошел работать и стал разбираться что мне нужно. Столкнулся с проблемой-разбирайся. И меньше временных затрат и больше пользы.
Я не знаю, что из того что мне преподают мне действительно будет необходимо. Именно по-этому я пошел работать и стал разбираться что мне нужно. Столкнулся с проблемой-разбирайся. И меньше временных затрат и больше пользы.
По 10 предметам 5-6 рекомендованных книг и это за 6 месяцев. Но кто это читает?
Тогда понятно, откуда такие проблемы. 5-6 книг за полгода — это, вообще-то, немного. В некий момент моего обучения мне приходилось читать по несколько книг в неделю (понятное дело, что реально читаешь ты одну, а остальные — просматриваешь в поисках конкретных нужных мест).
Столкнулся с проблемой-разбирайся.
Вот в этот момент и нужно было прочитать хотя бы немножко литературы.
Вот в этот момент и нужно было прочитать хотя бы немножко литературы.
Так и разбирался я в эти моменты.
Тогда понятно, откуда такие проблемы. 5-6 книг за полгода — это, вообще-то, немного. В некий момент моего обучения мне приходилось читать по несколько книг в неделю (понятное дело, что реально читаешь ты одну, а остальные — просматриваешь в поисках конкретных нужных мест).
5 книг за семестр это нормально, у меня даже немного больше выходит, если еще считать профессиональные книги не по специальности. Проблема в том, что список большой, книг дают много, и какую из них стоит прочесть в первую очередь, так как она раскрывает самые практические моменты, вопрос сложный.
Что касается написания ТЗ, то на учебном курсе, посвященному этой теме я заслуженно получил 5, и на тот момент решил, что углубляться в тему мне пока не нужно.
До сих пор считаете, что заслуженно?
Если брать в сравнении то да. Основным в курсе было изучения UML-диаграмм и с ними у меня нет никаких проблем и по сей день.
На ТЗ же смотрели, как на сдачу домашних работ в одной итоговой работе. На ошибки написания самого ТЗ никто внимания не обращал. Из-за этого и вопросов по его написанию не возникало. Казалось что работы была выполнена верно.
На ТЗ же смотрели, как на сдачу домашних работ в одной итоговой работе. На ошибки написания самого ТЗ никто внимания не обращал. Из-за этого и вопросов по его написанию не возникало. Казалось что работы была выполнена верно.
столкнутьсяtsya.ru
Ну что вы на человека накинулись?
Конечно, в России «руководителем проектов» теперь становится каждая собака — ведь это ж модно и панацея — проектный офис. Что это и как знают немногие, а потому и получается, что ПМ занимается не созданием устава и плана управления проектом, а написанием тз и кодингом. Это даже на руководителя группы (лида) не тянет. Обычно по правилу «хрен-пойми-как» становится в каждой бочке затычкой, а потому, потенциально, имеет большие возможности для развития.
Тем не менее, если наводить порядок в голове после института, то стоит разграничить все области — аналитику, разработку, тестирование, качество, поддержку, и управление. Собственно в случае автора — это разделение на
— PM, который работает по Agile или PMBOK (допустим),
— и на аналитика, который, вообще говоря, тоже подразделяется на бизнес-аналитика (BABOK/OMG) и технического, который сильно зависит от сферы, где он
нужен…
Конечно, в России «руководителем проектов» теперь становится каждая собака — ведь это ж модно и панацея — проектный офис. Что это и как знают немногие, а потому и получается, что ПМ занимается не созданием устава и плана управления проектом, а написанием тз и кодингом. Это даже на руководителя группы (лида) не тянет. Обычно по правилу «хрен-пойми-как» становится в каждой бочке затычкой, а потому, потенциально, имеет большие возможности для развития.
Тем не менее, если наводить порядок в голове после института, то стоит разграничить все области — аналитику, разработку, тестирование, качество, поддержку, и управление. Собственно в случае автора — это разделение на
— PM, который работает по Agile или PMBOK (допустим),
— и на аналитика, который, вообще говоря, тоже подразделяется на бизнес-аналитика (BABOK/OMG) и технического, который сильно зависит от сферы, где он
нужен…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я писал свое первое техническое задание