Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Как Вы считаете, может ли разработчик участвовать на первых ролях в составлении ТЗ?
Ответить на Ваш вопрос в общем виде я не могу, потому что всё зависит от конкретной ситуации. Рассматривая конкретный случай, я бы обращал внимание на масштаб проекта, его сложность, а также на профессиональный уровень всей команды разработчиков и отдельных её участников. Чем сложнее и больше проект, тем более крупные (и дорогие) ошибки могут допустить лица, мало понимающие в разработке. Я говорю об ошибках в уровне детализации задач, выставлении сроков, и прочих. Задача разработчика в этой ситуации — помогать не допустить этих оплошностей. На деле это может быть практически любой программист, который знает разрабатываемый продукт _широко_. Толковый разработчик поможет расписать задачу, прикинет время по отдельным пунктам или предупредит, что такой-то пункт надо прогнозировать отдельно и точнее, и т.д.
С другой стороны, доверять написание ТЗ самому исполнителю не кажется мне хорошей практикой. Мне видится, чтов небольших проетках реалистичное по срокам ТЗ легче всего достигается именно в связке «заказчик»-«разработчик», а не отдельными лицами.
В случае с крупными проектами, возможно эффективнее привлекать сторонних экспертов. Но не стоит забывать, что потом реализовывать всё нам, а не им. Про большие проекты ничего не могу сказать больше, так как участвовал в них давно и был совсем зелёный.
С другой стороны, доверять написание ТЗ самому исполнителю не кажется мне хорошей практикой. Мне видится, чтов небольших проетках реалистичное по срокам ТЗ легче всего достигается именно в связке «заказчик»-«разработчик», а не отдельными лицами.
В случае с крупными проектами, возможно эффективнее привлекать сторонних экспертов. Но не стоит забывать, что потом реализовывать всё нам, а не им. Про большие проекты ничего не могу сказать больше, так как участвовал в них давно и был совсем зелёный.
не туда ответил: habrahabr.ru/blogs/pm/106843/#comment_3364649
Задача программиста при написании ТЗ — понимать и оценивать сложность/возможность/невозможность реализации каких-то технических сторон, исходя из собственных знаний и умений. Он же может оценивать сроки на разработку (если при этом ещё и календарный план составляется)…
Единственное, программист не должен вмешиваться в бизнес-логику и дизайн — там свои эксперты найдутся.
А в итоге решение принимает ПМ, который и несет генеральную ответственность за проект.
Единственное, программист не должен вмешиваться в бизнес-логику и дизайн — там свои эксперты найдутся.
А в итоге решение принимает ПМ, который и несет генеральную ответственность за проект.
Моя любимая цитата из книги Эрика Синка в книге «Бизнес для программистов»:
Таким образом, разработчик может участвовать в составлении ТЗ на первых ролях. :)
Конечно, это очень общее соображение. Все проекты уникальны, и существует множество нюансов — проектная культура компании, принятое распределение ролей, тип и цель проекта и так далее и тому подобное. Но я безусловно согласен с первым ответом в этой ветке: «реалистичное по срокам ТЗ легче всего достигается именно в связке «заказчик»-«разработчик», а не отдельными лицами.»
Программисты не пишут спецификации и автоматизированные тесты. Они не помогают поддерживать автоматическую систему сборки продукта. Они не помогают клиентам. Они не помогают составлять документацию и тестировать продукт. Они даже не читают программный код, только пишут. В маленькой компании такие люди не нужны.
Вам нужны не программисты (те, кто только пишет код), а разработчики (те, кто готов выполнять любую работу на благо продукта).
Таким образом, разработчик может участвовать в составлении ТЗ на первых ролях. :)
Конечно, это очень общее соображение. Все проекты уникальны, и существует множество нюансов — проектная культура компании, принятое распределение ролей, тип и цель проекта и так далее и тому подобное. Но я безусловно согласен с первым ответом в этой ветке: «реалистичное по срокам ТЗ легче всего достигается именно в связке «заказчик»-«разработчик», а не отдельными лицами.»
Может, но ограниченно. Если это обычный разработчик (по роли не пм, не бизнес-аналитик, не архитектор и не продвигается на эти роли), то может участвовать, когда готов черновик ТЗ. На этом этапе желательно всем членам проектной команды (не только программистам, но и тестировщикам, верстальщикам, дизайнерам, ...) показать черновик и услышать их отзыв (по полноте, срокам, рискам, предложениям, ошибкам, ...). Если команда опытная и серьезно отнесется к отзыву, то можно получить ценные замечания, и обновить ТЗ с их учетом.
Менеджеру проекта следует оговаривать с заказчиком одни сроки, а с разработчиками — другие.
Опасное это дело — врать.
Не врать, а наоборот, перезакладываться. Ложь подразумевает сокрытие фактов, а тут никто ничего не скрывает. Просто сначала с разработчиками планируешь проект и получается, допустим, 70 единиц времени, а потом заказчиком договариваешься, что он может рассчитывать на готовность проекта через 100 единиц времени.
Заложить дополнительное время на тушение пожаров, больничные, отпуска, ошибки и т.п. — обязательно. Непонятно, почему программист не должен знать реальные сроки и существующий запас времени. Это важная для команды информация.
Ну это очень спорный момент, знание о потенциально существующем реальном дедлайне приведет к тому что будет соблазн заехать за виртуальный, «ведь он ничего не решает», посему в идеале их должно быть три, виртуальный, виртуальный «реальный», и реальный, когда проект будет отдан заказчику в готовом виде.
Первый дедлайн — для разработчиков, второй — для менеджеров проектов, третий — для начальства и заказчиков, если программисты заехали за свой дедлайн — для менеджера есть повод обеспокоиться судьбой проекта поактивнее, если менеджер заехал за свой — это уже повод для беспокойства руководящего состава, потому как третий дедлайн — последний.
Первый дедлайн — для разработчиков, второй — для менеджеров проектов, третий — для начальства и заказчиков, если программисты заехали за свой дедлайн — для менеджера есть повод обеспокоиться судьбой проекта поактивнее, если менеджер заехал за свой — это уже повод для беспокойства руководящего состава, потому как третий дедлайн — последний.
Ну да, поэтому дедлайн должен быть один. Но выставлен он должен быть с учетом фокус-фактора. Мотивировать же разработчиков писать код быстрее, искусственно сужая временные рамки проекта — едва ли продуктивно в долгосрочной перспективе.
А где здесь урезание? Время разработки проекта было оценено в месяц, с учетом пресловутого фокус-фактора — проект и должен быть разработан за месяц, почему исполнителя должно волновать что «на самом-то деле!» заказчик ждет проект через два? Второй месяц — это НЗ, который существует для того чтобы контора-исполнитель в случае каких-бы то ни было форс-мажорных обстоятельств не потеряла перед заказчиком лицо. Что лучше в случае срыва срока разработки — выделить время из этого НЗ или оправдываться перед заказчиком «вот вы понимаете, „два циклона и три ааантициклона...“ (с) м/ф Магазинчик Бо». Хороший руководитель на то и хороший руководитель, чтобы всегда иметь в рукаве туз.
Не обязательно врать. Менеджер таким образом устанавливает реальные сроки для себя и команды, если так и есть, то команда кивает и приступает к работе. Программисты не должны интересоваться, когда же настоящий момент дедлайна, до которого можно дотянуть.
> Эти правила должны соблюдаться, а о сделанных исключениях из правил желательно, чтобы никто не знал.
Детский сад, ей-богу! Не узнал… СМЕШНО!!!
Детский сад, ей-богу! Не узнал… СМЕШНО!!!
}}} Большинство программ пишутся с использованием
}}} классных сторонних библиотек, а то и целых фрэймворков
Это тоже нередко (замечу нередко, а не всегда) ошибка.
Не все хотят второй гугл или десятых однокласников, иногда требуется сайт-визитка для небольшой (например) строительной фирмы (на 5 статичных HTML страничек) Вместо этого нередко пишется многомегабайтный монстр написание которого в 100 раз дольше, в 500 раз дороже и после этого ещё и требует постоянной (и нудной) поддержки. Не важно ошибка это заказчика, или попытка исполнителя навариться, этого надо избегать, в отличии от теории (исполнители убедили в необходимости и содрали много денег, или заказчик думает что получит дорогой=хороший продукт) на практике в итоге никто от этого не выигрывает.
}}} классных сторонних библиотек, а то и целых фрэймворков
Это тоже нередко (замечу нередко, а не всегда) ошибка.
Не все хотят второй гугл или десятых однокласников, иногда требуется сайт-визитка для небольшой (например) строительной фирмы (на 5 статичных HTML страничек) Вместо этого нередко пишется многомегабайтный монстр написание которого в 100 раз дольше, в 500 раз дороже и после этого ещё и требует постоянной (и нудной) поддержки. Не важно ошибка это заказчика, или попытка исполнителя навариться, этого надо избегать, в отличии от теории (исполнители убедили в необходимости и содрали много денег, или заказчик думает что получит дорогой=хороший продукт) на практике в итоге никто от этого не выигрывает.
Если создание сайтов-визиток — одно из основных направлений фирмы, то поддерживать цмску проблемой не будет.
Делать сайты-визитки в статике — это полный бред (за исключением презентационных конфеток). Тот же Drupal, поставленный на поток, идеально эффективен для сайтов-визиток, и богатейший функционал этого факта не отменяет.
Делать сайты-визитки в статике — это полный бред (за исключением презентационных конфеток). Тот же Drupal, поставленный на поток, идеально эффективен для сайтов-визиток, и богатейший функционал этого факта не отменяет.
Зачем одной страничке с адресом (оф-лайновым) и телефоном (ну и ешё паре страниц с восхвалением самих себя) нужно иметь двиган на РНР размером в мегабайты кода?
Это оверинженеринг в самом классическом его проявлении, и именно он не редко является причиной уязвимостей для сервера (и как следствие финансовыми убытками в случае взлома) да и вообще вселенским злом в целом!!!
Это оверинженеринг в самом классическом его проявлении, и именно он не редко является причиной уязвимостей для сервера (и как следствие финансовыми убытками в случае взлома) да и вообще вселенским злом в целом!!!
Всё это, конечно, хорошо, фреймворки, инструменты, процессы, но на самом деле в срыве сроков виноват руководитель (в Вашей классификации — менеджер) и только он. Всё остальное — оправдания.
А какова была первоначальная оценка фич, на которые вам как правило не хватало от 5 до 10 дней? И если их всегда, раз за разом, не хватало почему, не включали эти «лишние» дни в оценку?
В разных местах были разные причины срыва. Были случаи, когда я как исполнитель (разработчик) не успевал что-то сделать из-за низких навыков, например.
Иногда таки менеджер ошибался со сроками не посовещавшись с программистами.
На настоящем же проекте мы постоянно не успеваем из-за того, что в тот момент, когда проектный договор подписывался, никто толком его не проверил. В результате имеем тучу работы, (за)критически мало трудовых ресурсов и очень «хорошие» сроки. Это нехороший пример «русского бизнеса». Оценку сроков якобы проводил сам заказчик. На момент подписания договора у нас в конторе был только один программист и тот слабенький (оценить риски неисполнения договора он бы не смог). А ещё одного специалиста и меня взяли примерно через 2,5 и 5 месяцев после запуска. Пока расхлябываем не так плохо, как я думал. И я не устаю повторять менеджеру про сроки и потребность в рабочих руках.
Иногда таки менеджер ошибался со сроками не посовещавшись с программистами.
На настоящем же проекте мы постоянно не успеваем из-за того, что в тот момент, когда проектный договор подписывался, никто толком его не проверил. В результате имеем тучу работы, (за)критически мало трудовых ресурсов и очень «хорошие» сроки. Это нехороший пример «русского бизнеса». Оценку сроков якобы проводил сам заказчик. На момент подписания договора у нас в конторе был только один программист и тот слабенький (оценить риски неисполнения договора он бы не смог). А ещё одного специалиста и меня взяли примерно через 2,5 и 5 месяцев после запуска. Пока расхлябываем не так плохо, как я думал. И я не устаю повторять менеджеру про сроки и потребность в рабочих руках.
В целом всё написано правильно, всё верно.
Но по моему опыту, наиболее частая причина срыва сроков — когда заказчик начинает «капризничать»: «Мы совсем не это имели ввиду! Вот это надо понимать вот так, а вот это — вот так!»
Очень сложная задача — составить ТЗ таким образом, чтобы заказчик его принял, но и чтобы свои интересы были соблюдены. Особенно это заметно при работе с очень большими корпоративными заказчиками, когда малейшее изменение ТЗ приводит к необходимости согласования «по большому кругу». Такие проекты очень тяжело начать, но еще сложнее — завершить. «Хотелки» начинают вырастать на глазах…
Единственный варинат, когда такой ситуации можно избежать: писать ТЗ не в терминах реализации функциональности, а в терминах реализации сценариев использования. Тогда «хотелки» фильтруются на раз: «В наших сценариях, под которыми вы уже поставили свою подпись, такая функциональность не используется. Это вообще другой сценарий, который мы предлагаем реализовать во втором этапе проекта.»
Но по моему опыту, наиболее частая причина срыва сроков — когда заказчик начинает «капризничать»: «Мы совсем не это имели ввиду! Вот это надо понимать вот так, а вот это — вот так!»
Очень сложная задача — составить ТЗ таким образом, чтобы заказчик его принял, но и чтобы свои интересы были соблюдены. Особенно это заметно при работе с очень большими корпоративными заказчиками, когда малейшее изменение ТЗ приводит к необходимости согласования «по большому кругу». Такие проекты очень тяжело начать, но еще сложнее — завершить. «Хотелки» начинают вырастать на глазах…
Единственный варинат, когда такой ситуации можно избежать: писать ТЗ не в терминах реализации функциональности, а в терминах реализации сценариев использования. Тогда «хотелки» фильтруются на раз: «В наших сценариях, под которыми вы уже поставили свою подпись, такая функциональность не используется. Это вообще другой сценарий, который мы предлагаем реализовать во втором этапе проекта.»
Спасибо за хорошее замечание про «капризы». Не написал об этом потому двум причинам. Во-первых, элементарно не вспомнил :). Во-вторых, у нас, когда коллеги составляют требования, мне как программисту очень тяжело что-то в них изменить (таков уж проект). Максимум, что я могу это: а) задать ряд «философских» вопросов, отвечая на которые автор изменений либо утвердиться в необходимости, либо поставит под сомнение нужность правок; б) объяснить цену внесения этих изменений авторам и руководству, а они уж решат, стоит ли овчинка выделки. Но в целом я стараюсь придерживаться лозунга, что «заказчику виднее».
Существует очень эффективная техника оценки сроков выполнения, всё шире используемая в Agile-подходах к разработке: Planning Poker. На первый взгляд примитивная, но на самом деле в ней продумано множество мелочей:
— в оценке участвует вся команда (то есть сроки не спускаются «сверху»);
— в процессе оценки естественным образом рассматривается большинство рисков (когда люди, давшие минимальную и максимальную оценку объясняют всем остальным, почему они думают именно так);
— есть защита от психологического давления со стороны человека, заинтересованного в минимальной оценке сроков (карты открываются только после того, как все участники выложили свою оценку).
Мы применяли этот способ в нашей команде, и он давал на удивление реалистичные оценки. То есть буквально с точностью до дня — я сам не верил, что такое возможно.
— в оценке участвует вся команда (то есть сроки не спускаются «сверху»);
— в процессе оценки естественным образом рассматривается большинство рисков (когда люди, давшие минимальную и максимальную оценку объясняют всем остальным, почему они думают именно так);
— есть защита от психологического давления со стороны человека, заинтересованного в минимальной оценке сроков (карты открываются только после того, как все участники выложили свою оценку).
Мы применяли этот способ в нашей команде, и он давал на удивление реалистичные оценки. То есть буквально с точностью до дня — я сам не верил, что такое возможно.
Мы для временных оценок пользовались методом Wideband Delphi, по сути, то же самое, но без карточек (Planning Poker сделан на его основе).
Неплохо, но есть несколько замечаний.
«Закрытых задач» не бывает если только проэкт не умер. Требования меняются и в второй-третей версии придётся что-то менять. Тут нужно больше боротся с «исполнением на коленке» когда задачу помечают как исполненую, но реализация некачественная и потом постоянно приходится возвращатся к ней.
Комуникация: личный разговор отвлекает сильнее («вырывает из потока») чем простое сообщение в чат. Тут зависит от важности и срочности задачи. И тут больше действует возможно ваше личное восприятие разных каналов комуникации. Кроме того при включеном логировании чат имеет свойство автоматического документирования принятого решения, что при беседе не работает («я такого не говорил»). Конечно что важные решения должны заносится в какую-то систему, а не хранится на листике или в чатике, но простое обсуждение Васи и Коли как сделать эту загогулину в чате поможет Васе на следующий день после гулянки вспомнить о чём же они договорились не дёргая Колю попусту. Да и в той же комнате где сидит 10 человек мне не нужно кричать чтобы спросить где такая-то штука реализирована, решается проблема с шумом.
«Закрытых задач» не бывает если только проэкт не умер. Требования меняются и в второй-третей версии придётся что-то менять. Тут нужно больше боротся с «исполнением на коленке» когда задачу помечают как исполненую, но реализация некачественная и потом постоянно приходится возвращатся к ней.
Комуникация: личный разговор отвлекает сильнее («вырывает из потока») чем простое сообщение в чат. Тут зависит от важности и срочности задачи. И тут больше действует возможно ваше личное восприятие разных каналов комуникации. Кроме того при включеном логировании чат имеет свойство автоматического документирования принятого решения, что при беседе не работает («я такого не говорил»). Конечно что важные решения должны заносится в какую-то систему, а не хранится на листике или в чатике, но простое обсуждение Васи и Коли как сделать эту загогулину в чате поможет Васе на следующий день после гулянки вспомнить о чём же они договорились не дёргая Колю попусту. Да и в той же комнате где сидит 10 человек мне не нужно кричать чтобы спросить где такая-то штука реализирована, решается проблема с шумом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему программисты срывают сроки