Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Иной раз заказчика не интересует быстро и дешево (в разумных пределах), но часто ему нужны конкретные сроки и конкретные суммы. Особенно это заметно при работе с государственными учреждениями или просто теми, где белая бухгалтерия, большая бюрократия, в общем, выделение лишней 1000 рублей (сверх договорных 30 000) может затянуться на месяцы…
Мораль статьи: разработчикам — общайтесь с заказчиком, важно иметь обратную связь на всех этапах разработки. Заказчикам — будьте конкретны в тех вещах, которые для вас важны и тоже общайтесь: разработчики — не телепаты.
Простите, но даже на хабре уже в мильоный раз читаю подобный пост. В других хотя бы советы были… You are welcome!
Может out staffing? Например, так: мы можем предоставить любой квалификации специалистов на любой ваш проект на любое нужное вам время. Наши рейты за час работы таких-то специалистов такие, в них заложены административные и пр. расходы, а также прибыль компании.
Можете уменьшить риски оплатив дополнительное время дополнительных специалистов в команде.
По нашим предварительным оценкам проект займет N месяцев и ежемесячный расход на команду X тыс. $.
Это такой себе time & material.
Не делайте «нетиповых» сложных проектов по схеме fixed price и нервы целее будут.
А общаться с заказчиком надо и очень много и плотно.
Можете уменьшить риски оплатив дополнительное время дополнительных специалистов в команде.
По нашим предварительным оценкам проект займет N месяцев и ежемесячный расход на команду X тыс. $.
Это такой себе time & material.
Не делайте «нетиповых» сложных проектов по схеме fixed price и нервы целее будут.
А общаться с заказчиком надо и очень много и плотно.
серебряная пуля есть — дробите проект и оценивайте каждую часть отдельно, как это делается в том же скраме.
И да, статья не заслуживает такого названия.
И да, статья не заслуживает такого названия.
не поможет в случае, если надо выдать полную оценку проекта, редко когда встречаются заказчики, которых устраивает точная оценка одного этапа и отсутствие полной. а скрам как раз позволяет быть очень точным в деталях (в рамках спринта можно точно прогнозировать время), но сказать, что дом будет достроен через три месяца — скрам тут не поможет, насколько я понимаю
В скраме каждый спринт, как правило, дает заказчику дом в каком-то виде: с каждым спринтом дом обрастает все большим и большим количеством фитч (для дома это скажем перегородки в комнатах, стеклопакеты на окнах, отделка). Так заказчик каждый спринт остается доволен — построен еще не весь дом со всем набором фитч, но то, что уже есть вполне напоминает конечный результат, а в лучшем случае этим уже можно пользоваться. Если постараться построить работу так (рекомендаций есть много), то и разработчики и заказчик должны оставаться довольными.
Первоначальная оценка сроков всегда остается предварительной, с этим трудно что-то сделать. Можно только ошибиться чуть больше или намнооого больше :)
Первоначальная оценка сроков всегда остается предварительной, с этим трудно что-то сделать. Можно только ошибиться чуть больше или намнооого больше :)
Кажется мне, проблема высосана из пальца.
Точнее, это проблема может возникнуть только у недобросовестных заказчиков и исполнителей.
А нормальный проект можно сделать только по ТЗ. Основываясь на вашем примере со строителями, в ТЗ НЕ МОЖЕТ НЕ БЫТЬ не описано, что в доме должна быть арка.
Вот она и радость заказчиков и разработчиков — сначала разработчик «оптичивает» ТЗ пункт за пунктом и получает удовольствие от каждой реализованной фичи ( = проставленной птички), потом заказчик «оптичивает» ТЗ при приёме работы.
И все счастливы.
Отдельный вопрос — разработка ТЗ. В тех случаях, когда заказчик не в состоянии написать ТЗ, оно обычно разрабатывается исполнителями за отдельную плату.
Точнее, это проблема может возникнуть только у недобросовестных заказчиков и исполнителей.
А нормальный проект можно сделать только по ТЗ. Основываясь на вашем примере со строителями, в ТЗ НЕ МОЖЕТ НЕ БЫТЬ не описано, что в доме должна быть арка.
Вот она и радость заказчиков и разработчиков — сначала разработчик «оптичивает» ТЗ пункт за пунктом и получает удовольствие от каждой реализованной фичи ( = проставленной птички), потом заказчик «оптичивает» ТЗ при приёме работы.
И все счастливы.
Отдельный вопрос — разработка ТЗ. В тех случаях, когда заказчик не в состоянии написать ТЗ, оно обычно разрабатывается исполнителями за отдельную плату.
* в ТЗ НЕ МОЖЕТ БЫТЬ НЕ описано :)
Только вот случаи, когда заказчик не в состоянии написать ТЗ, обычно составляют 99% от всех возможных.
ТЗ должен писать исполнитель (по начальной постановке, составленной совместно):
1. аналогия с постановкой задачи сотруднику: прежде всего убедиться, что тот все правильно понял. железный вариант — сотрудник сам повторяет формулировку задачи, а руководитель при необходимости придирается. Так и ТЗ — детальную постановку задачи — пишет подрядчик, а заказчик придирается: придраться легче, чем сделать самому — волшебное правило начальника, и по небольшому проценту выявленных проблем можно судить о качестве подрядчика в целом
2. в ТЗ нужно прописывать и нефункциональные требования — их лучше знает и может определить исполнитель (и здесь опыт предыдущих проектов как раз работает): от времени отклика до системных требований / поддерживаемых версий платформы / гарантийного периода / сроках реакции заказчика /… еще много…
3. так давно и работают профессионалы, тем более на больших проектах и в отраслях, где цена ошибки постановки задачи еще выше — есть целые проектные институты.
4. Несколько лет личного опыта: на стороне исполнителя избегал больших проблем, написав предварительно ТЗ, а на стороне заказчика влетал в проблемы, по привычке написав ТЗ сам, но уже не так детально (исполнители влетали еще сильнее, но от этого радости мало).
НО! В прикладных IT-проектах вредно в ТЗ закладывать все функциональные требования — они меняются либо неизвестны изначально. А вот нефункциональные, сквозные — как раз стоит, чтобы соблюдать/проверять на всех этапах проекта или осознанно менять.
<без_лишней_скромности>эх, комментарий-то содержательнее поста...</блс>
1. аналогия с постановкой задачи сотруднику: прежде всего убедиться, что тот все правильно понял. железный вариант — сотрудник сам повторяет формулировку задачи, а руководитель при необходимости придирается. Так и ТЗ — детальную постановку задачи — пишет подрядчик, а заказчик придирается: придраться легче, чем сделать самому — волшебное правило начальника, и по небольшому проценту выявленных проблем можно судить о качестве подрядчика в целом
2. в ТЗ нужно прописывать и нефункциональные требования — их лучше знает и может определить исполнитель (и здесь опыт предыдущих проектов как раз работает): от времени отклика до системных требований / поддерживаемых версий платформы / гарантийного периода / сроках реакции заказчика /… еще много…
3. так давно и работают профессионалы, тем более на больших проектах и в отраслях, где цена ошибки постановки задачи еще выше — есть целые проектные институты.
4. Несколько лет личного опыта: на стороне исполнителя избегал больших проблем, написав предварительно ТЗ, а на стороне заказчика влетал в проблемы, по привычке написав ТЗ сам, но уже не так детально (исполнители влетали еще сильнее, но от этого радости мало).
НО! В прикладных IT-проектах вредно в ТЗ закладывать все функциональные требования — они меняются либо неизвестны изначально. А вот нефункциональные, сквозные — как раз стоит, чтобы соблюдать/проверять на всех этапах проекта или осознанно менять.
<без_лишней_скромности>эх, комментарий-то содержательнее поста...</блс>
а расскажите, что за проблемы возникают, когда ТЗ пишет заказчик, и почему при этом влетали исполнители?
из последнего:
Заказываем на аутсорсинг айфон-приложение. ТЗ пишем сами — только функциональное. Подрядчики его принимают, начинаем разработку.
Во время разработки iOS обновляется с 3.x до 4.0-4.2, выходит iPhone 3GS, iPad. Выпущенное приложение начинает критически глючить на новых устройствах и версиях ОС.
Пользователи жалуются на баги, мы воспринимаем это как баги — соответственно, не закрываем проект, пока не получим стабильную работу на всех версиях. Подрядчики получают новую работу за те же деньги, не вошедшую в первоначальный расчет, заказчик недоволен подрядчиками, пользователи недовольны продуктом (а это дороже, чем экономия на «бесплатной» работе подрядчика).
Как надо было: подрядчику продумать типовые нефункциональные требования, учесть, что глюки на новых версиях — норма (о них предупреждает сама Apple и заранее выпускает беты для проверки приложений), учесть это в ТЗ — оговорить поддерживаемые версии, оговорить условия поддержки новых версий).
Что бы получилось: у обеих сторон (прежде всего, у подрядчиков) в нужный момент сработал бы сигнал о задачах по поддержке новых версий платформы, делались они бы в штатном режиме (при любой договоренности об оплате), подрядчики бы не попали на дополнительный объем, мы бы не думали, что у подрядчиков столько косяков, пользователи бы не думали, что в продукте столько косяков — мы бы предупреждали о поддерживаемых версиях.
Заказываем на аутсорсинг айфон-приложение. ТЗ пишем сами — только функциональное. Подрядчики его принимают, начинаем разработку.
Во время разработки iOS обновляется с 3.x до 4.0-4.2, выходит iPhone 3GS, iPad. Выпущенное приложение начинает критически глючить на новых устройствах и версиях ОС.
Пользователи жалуются на баги, мы воспринимаем это как баги — соответственно, не закрываем проект, пока не получим стабильную работу на всех версиях. Подрядчики получают новую работу за те же деньги, не вошедшую в первоначальный расчет, заказчик недоволен подрядчиками, пользователи недовольны продуктом (а это дороже, чем экономия на «бесплатной» работе подрядчика).
Как надо было: подрядчику продумать типовые нефункциональные требования, учесть, что глюки на новых версиях — норма (о них предупреждает сама Apple и заранее выпускает беты для проверки приложений), учесть это в ТЗ — оговорить поддерживаемые версии, оговорить условия поддержки новых версий).
Что бы получилось: у обеих сторон (прежде всего, у подрядчиков) в нужный момент сработал бы сигнал о задачах по поддержке новых версий платформы, делались они бы в штатном режиме (при любой договоренности об оплате), подрядчики бы не попали на дополнительный объем, мы бы не думали, что у подрядчиков столько косяков, пользователи бы не думали, что в продукте столько косяков — мы бы предупреждали о поддерживаемых версиях.
Речь именно про инициацию проекта, когда нет еще никакой проектной документации, тз тоже нет. А сроки уже надо хоть какие-то выдвинуть.
конфликт интересов возникает каждый раз, у сторон имеющих эти самые интересы. даже если вы сели в такси, у вас уже конфликт с водителем — ему нужно дорого и быстро, вам дешево и быстро. нужно осознавать что такой конфликт есть и решать его мирным путем :)
Вот как раз читал сегодня в Getting Real, что не надо растягивать сроки, если не успеваете сделать. Нужно отказаться от каких-то фишек, которые затягивают процесс.
Ведь в конечном итоге цель у обеих сторон одна — удовлетворенность конечным продуктом.
По-моему — не всегда. Если Заказчик — это посредник, то у него обычно преобладает материальный интерес.
Тема второй части названия статьи совсем не раскрыта
Не понял что хотел сказать автор статьи. Да проблема существует, но есть стандартные пути ее решения.
1. Сначала написать ТЗ. Потом «строго» делать по ТЗ. Ответственность большей частью будет на заказчике. Упустил, не указал в ТЗ сам виноват.
2. Если заказчик не хочет/не может составить ТЗ. Agile/Srum/попросту почасовка. Делаем и походу разбираемся в том, что надо сделать :) Все переделки опять же оплачиваются заказчиком.
3. Если заказчика не устраивает, ни первое ни второе, то может не стоит связываться с таким заказчиком?
1. Сначала написать ТЗ. Потом «строго» делать по ТЗ. Ответственность большей частью будет на заказчике. Упустил, не указал в ТЗ сам виноват.
2. Если заказчик не хочет/не может составить ТЗ. Agile/Srum/попросту почасовка. Делаем и походу разбираемся в том, что надо сделать :) Все переделки опять же оплачиваются заказчиком.
3. Если заказчика не устраивает, ни первое ни второе, то может не стоит связываться с таким заказчиком?
Название не соответствует содержимому…
Статья ни о чём. Резюмирую весь текст:
— Существуют «белые» и «красные». «Белые» видят «красных» как «синих», а «красные» видят «белых» как «черных». Из-за этого у них проблемы.
— Существуют «белые» и «красные». «Белые» видят «красных» как «синих», а «красные» видят «белых» как «черных». Из-за этого у них проблемы.
название статьи вводит в заблуждение о её содержании
статья баян. Общение в Заказчиком зависит от методики разработки, которую Вы используете (RUP, SCRUM, XP). Попробуйте изучить эту тему и возможно тогда прийдет понимание в вопросе общения с Заказчиками.
Про pmbok еще забыли, если уж мешать вместе методики разработки и управления, но из этих методик только agile явно рекомендует Как надо общаться с заказчиком, в остальных он присутствует как что-то абстрактное, но несмненно опасное
kiote, возможно я не очень корректно выразился в отношении методики разработки и управления, но я пытался выразить некую мысль — общение с Заказчиком всегда индивдуально, так как зависит от множества составляющих…
Если вы уже знакомы с этими понятиями, тогда я думаю Вам должно быть понятно почему статья баян… А если нет, то я намекну.
Выбор манеры общения с Заказчиком в отношении сроков/стоимости и тп зависит от того на какой стадии находится Исполнитель и какую позицию в отношении общения с Заказчиком он выбирает.
Если Исполнитель профессионал с хорошим портфолио и авторитетом, то думаю вряд ли он будет гибким в отношениях с Заказчиком, поскольку общение будет вестись с позиции профессионала в своей области.
Однако есть исключения — например когда планируется разработка какого-то инновационного продукта или системы. В данном случае проект, как правило, не может быть описан полностью и как следствие — оговаривается лишь приблизительная сумма. Разработка в данном случае разбивается на этапы и оценка ведется в процессе итераций по факту затраченных человеко-часов.
Ну а если Исполнитель новичек, тогда учитывая «что дальнейшие рассуждения пойдут о веб-разработке относительно сложных и протяженных по времени продуктов» Заказчика в 90% случаев ждет негативный опыт, о котором Вы не забыли упомянуть в этот статье.
Если вы уже знакомы с этими понятиями, тогда я думаю Вам должно быть понятно почему статья баян… А если нет, то я намекну.
Выбор манеры общения с Заказчиком в отношении сроков/стоимости и тп зависит от того на какой стадии находится Исполнитель и какую позицию в отношении общения с Заказчиком он выбирает.
Если Исполнитель профессионал с хорошим портфолио и авторитетом, то думаю вряд ли он будет гибким в отношениях с Заказчиком, поскольку общение будет вестись с позиции профессионала в своей области.
Однако есть исключения — например когда планируется разработка какого-то инновационного продукта или системы. В данном случае проект, как правило, не может быть описан полностью и как следствие — оговаривается лишь приблизительная сумма. Разработка в данном случае разбивается на этапы и оценка ведется в процессе итераций по факту затраченных человеко-часов.
Ну а если Исполнитель новичек, тогда учитывая «что дальнейшие рассуждения пойдут о веб-разработке относительно сложных и протяженных по времени продуктов» Заказчика в 90% случаев ждет негативный опыт, о котором Вы не забыли упомянуть в этот статье.
Разработка в удовольствие — это чудо. Как умная красивая жена. Дай Вам Бог такой работы на всю жизнь.
Алан Купер написал об этом книгу:
На удивление писал о том же самом и с те ме аналогиями в своем блоге.
blog.weltkind.com/ru/work/secrets/?id=170
Цитирую:
Сроки.
Самое больное? А все почему? Основная причина срыва сроков – не изученные до конца потребности заказчика. Вы все детали обговорили? Какие он выбрал окна? Не те ли, что придется везти чартером из Турции, потому что больше их нигде не продают? А вот фотографий в форме редактирования сколько будет? Одна или сколько угодно с красивым флешевским загрузчиком под дизайн сайта?
Невозможно предугадать и описать все, но если у Вас большая практика, Вы всегда имеете статистику по рискам и задержкам. Умножьте на два и заложите ее в смету.
Закладывайте сроки с учетом выходных, праздников, кризиса на заводе шиферных изделий, даже дня рождения прораба через две недели. Как знать когда он сможет полноценно работать после него? И еще пару дней от себя.
Забудьте модели, когда Ваня и Петя на спор выложили за день стены. Такого больше не повторится. Ориентируйтесь на тихоню Пришта, который худо-бедно, но стабильно кладет 100 кирпичей в день. Пусть это будет эталоном оценки.
Если Вы не работали с технологиями, которые будут в проекте, либо будете использовать продукты от других производителей, заложите это в сроки! Не надейтесь что все пройдет гладко, как в тот раз с WYSIWYG-ом. Вспомните танцы с бубном при попытке поковырять код Битрикса. Неделя ушла? И все стояли ждали?
Заложите, наконец, те самые риски на переносы несущих стен.
А теперь стойте за эти сроки – как бойцы – Панфиловцы под Москвой. Ни шагу назад. Если клиент выторговывает 2-3 дня, значит, он жестко спросит за всякую просрочку.
Это Ваша самая главная роль! А не бегать с кнутом за сотрудниками, которые вынуждены, будут ночевать в офисе из-за того, что Вы по доброте душевной скинете пару недель.
Если клиент адекватен – он примет Ваши условия. Если же у него свои форс-мажеры, попробуйте решить эти проблемы вместе. Например, разделить работу на несколько этапов. Или быстро поставить картонные фанерки с изображением домика для начальника.
blog.weltkind.com/ru/work/secrets/?id=170
Цитирую:
Сроки.
Самое больное? А все почему? Основная причина срыва сроков – не изученные до конца потребности заказчика. Вы все детали обговорили? Какие он выбрал окна? Не те ли, что придется везти чартером из Турции, потому что больше их нигде не продают? А вот фотографий в форме редактирования сколько будет? Одна или сколько угодно с красивым флешевским загрузчиком под дизайн сайта?
Невозможно предугадать и описать все, но если у Вас большая практика, Вы всегда имеете статистику по рискам и задержкам. Умножьте на два и заложите ее в смету.
Закладывайте сроки с учетом выходных, праздников, кризиса на заводе шиферных изделий, даже дня рождения прораба через две недели. Как знать когда он сможет полноценно работать после него? И еще пару дней от себя.
Забудьте модели, когда Ваня и Петя на спор выложили за день стены. Такого больше не повторится. Ориентируйтесь на тихоню Пришта, который худо-бедно, но стабильно кладет 100 кирпичей в день. Пусть это будет эталоном оценки.
Если Вы не работали с технологиями, которые будут в проекте, либо будете использовать продукты от других производителей, заложите это в сроки! Не надейтесь что все пройдет гладко, как в тот раз с WYSIWYG-ом. Вспомните танцы с бубном при попытке поковырять код Битрикса. Неделя ушла? И все стояли ждали?
Заложите, наконец, те самые риски на переносы несущих стен.
А теперь стойте за эти сроки – как бойцы – Панфиловцы под Москвой. Ни шагу назад. Если клиент выторговывает 2-3 дня, значит, он жестко спросит за всякую просрочку.
Это Ваша самая главная роль! А не бегать с кнутом за сотрудниками, которые вынуждены, будут ночевать в офисе из-за того, что Вы по доброте душевной скинете пару недель.
Если клиент адекватен – он примет Ваши условия. Если же у него свои форс-мажеры, попробуйте решить эти проблемы вместе. Например, разделить работу на несколько этапов. Или быстро поставить картонные фанерки с изображением домика для начальника.
промышленная разработка в удовольствие — это миф
программирование в удовольствие — это реальность.
вот некоторые из типичных аргументов распространеной WEB студии:
всегда есть сроки, их нарушение порождает хаки и говнокод
не дают времени на освоение новых технологий. все проекты срочные, срок — вчера.
хочешь внедрить xUnit или что-то подобное — смотрят как на дурака
хочешь внедрить noSQL или что-то похожее — боятся, что если ты уйдешь, то ни кто без тебя не разберется.
в общем почти все, что я разрабатывал от души — все было в нерабочее время.
а может мне просто не везет с руководством или компанией
программирование в удовольствие — это реальность.
вот некоторые из типичных аргументов распространеной WEB студии:
всегда есть сроки, их нарушение порождает хаки и говнокод
не дают времени на освоение новых технологий. все проекты срочные, срок — вчера.
хочешь внедрить xUnit или что-то подобное — смотрят как на дурака
хочешь внедрить noSQL или что-то похожее — боятся, что если ты уйдешь, то ни кто без тебя не разберется.
в общем почти все, что я разрабатывал от души — все было в нерабочее время.
а может мне просто не везет с руководством или компанией
«не дают времени на освоение новых технологий. все проекты срочные, срок — вчера.
хочешь внедрить xUnit или что-то подобное — смотрят как на дурака
хочешь внедрить noSQL или что-то похожее — боятся, что если ты уйдешь, то ни кто без тебя не разберется.»
было такое только в одной компании, таких надо вовремя распознавать и сваливать на…
хочешь внедрить xUnit или что-то подобное — смотрят как на дурака
хочешь внедрить noSQL или что-то похожее — боятся, что если ты уйдешь, то ни кто без тебя не разберется.»
было такое только в одной компании, таких надо вовремя распознавать и сваливать на…
иногда уже просто не куда сваливать.
а сваливать на меньшие деньги как-то жизнь не позволяет. Семья. Кредит. Прочие обязанности.
а сваливать на меньшие деньги как-то жизнь не позволяет. Семья. Кредит. Прочие обязанности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Капканы веб-разработки или веб- разработка в удовольствие