Заказчик (З): Сколько займет сделать калькулятор?
Исполнитель (И): А.. понты, задача легкая, за два дня справлюсь.
Прошло два дня.
И: Я калькулятор сделал. Исходники только что выслал.
З(робко): А можно что-то, чтобы я мог запустить.
И: Да, без проблем — .exe послал.
З: Оно что-то говорит о том, что не хватает какого-то .NET framework
И: А блин… Так нужно его сказать с http://… , потом поставить
З (через час): ok, Оно запустилось, но выглядет просто ужастно. Мне нужен нормально выглядящий калькулятор.
И: От блин. Я вообще дизайном не занимаюсь, но попытаюсь что-то сделать.
Через день
И: Вот, поглядите.
З: А можно, это сделать чуть больше, тут цвета поменять, тут еще что-то подправить.
И: ok. Сейчас прямо сделаю. (Делает)
З: ok. Так вроде нормально. Так, насчет установки. Честно говоря, мои клиенты не захотят с этим .NET установкой возится, сделай, чтобы можно было по Next проходить.
И: Оk. (В мыслях — как он меня достал, я ему не подписывался все это делать). Завтра сделаю.
Через день.
И: Сделал.
З: Надеюсь, оно же будет работать и на XP и на Vista?
И: А… хм… черт его знает. Я на Vista не пробовал.
З: Ладно, я сам попробую. …. Ага вроде работает, но почему-то выдает сообщение о том, что какой-то файл не найден. Это нужно исправить.
И: А откуда же я в Vista возьму? Давайте я вам пошлю отладочную версию, вы ее запустите, пришлете логи, а я потом поправлю.
Еще один день проходит в отладке.
З: ok. Вроде установка работает. Я покасуть до дело попробовал, и почему-то если сложить 2 + 2 получается 5, а если поделить на ноль то он вообще вылетает.
И: О.. Блин, так что я все комбинации должен был проверять (уже сильно нервничая).
З: Не фига себе, а ты что вообще пытался им пользоваться.
И: Ну, почему-же не тестировал… Тестировал — 1+1 проверял, что выходит 2 и 1*1=1.
З: Так, мне нужно это дело серьезно проверить, чтобы ошибок не было.Чтобы до завтра было готово, и так уже сроки затянул.
И: ok. Но это я уже точно не обещал, так что требую дополнительную плату. (Про себя Этот заказчик @!#!@#).
З: Черт с тобой, половину от того, что требуешь оплачиваю — остальное нет, так как полное говно, я тоже не собирался у тебя покупать. (Про себя Этот исполнитель @!#!@#).
Прошло 2 дня, все более менее оттестировано.
З: Ну, ok. Вроде все нормально работает. А где help у калькулятора?
И: (Чуть не падая под стол). Какой еще help?
З: Ну, для того, чтобы объяснить как все функции работают.
И: Не, этого я точно делать не буду. Я и писать то не умею.
З: ok. Ладно, я сам напишу. Но мне нужно, чтобы это выглядело, как стандартный help файл.
И: ok. Присылай.
З: Присылает word документ на 10 страниц.
И: Ой блин… Так мне теперь надо разобраться как это все запихнуть в hlp файл.
Еще проходит день и все запихнуто.
З: Ну, все, вроде все работает. Вот тебе деньги, хотя ты бездарь их не заработал. Говорил 2 дня займет, а мы тут уже чуть ли не две недели ковыряемся.
Входит новое (виртуальное) действующее лицо — покупатель (П). Виртуальное, так как это не конкретный покупатель, а очень обобщенный.
З: Покупайте калькулятор — бакс, одна штука.
В ответ тишина.
З: От блин… Надо же сайт сделать и выложить на другие сайты рекламу. (Привлекается исполнитель для создания сайта.)
З (снова): Покупайте калькулятор — бакс, одна штука.
П: ok, теперь слышу, хотя редко и плохо. Но, нафига мне собственно говоря, покупать твой калькулятор — у меня в Windows встроенный.
З: Ой блин… А действительно, я и не знал, что в Windows он уже есть. Идет к исполнителю, добавить крутых функций и выкладывает на сайт.
П: Да, крутые функции у тебя есть, но мне нафиг они не нужны.
З: Оглядываясь. А кому они вообще нужны? Находит, что математикам нужны.
З: Математики, покупайте калькулятор — бакс, одна штука.
В ответ опять тишина.
З: Ну, что же все так херово идет. Делает рекламу в журналах для математиков.
П: о… Вроде то, что надо. Начинают покупать. Хотя в начале возьму пробную бесплатную версию на 30 дней.
Проходит время.
П: Что-то у меня это плохо работает и это не работает, да и это борохлит. Если исправите, копию куплю.
З: Устав уже отвечать на email’ы и звонки, нанимает девочку, которая делает это за него. А исполнитель постепенно все поправляет.
П: Ну, теперь вроде все ok. Вот твои заслуженные $1 за калькулятор.
Вот такая грустная история 🙂
По мотивам истории:
Продукт = Реализация + тестирование + инсталяционный пакет + документация + веб сайт+ реклама + маркетинг + поддержка + еще тьма всего.
Особенно актуальна эта формула, если вы собираетесь сами делать продукт, либо помогаете неопытному заказчику.
Большинство небольших заказчиков это не понимают и не хотят понять, благо есть еще студенты которые работают за еду:) И не говорите что заказчики потом возвращаются к нормальным разработчикам, им потом проще купить уже разработанное но кривое приложение 🙂
p/s
А когда разработчики сами начинают делать продукт, то это действительно реальные грабли. Обычно разработчики только код пишут из вышеперечисленного 🙂
Чаще всего если заказчик этого не понимает, то долго он в бизнесе не остается.
Это же самое относится и к студентам работающим за еду.
Да, действительно разработчики часто этим страдают, что они видят продукт только с точки зрения кода.
В сытое время такие заказчики все-же живут. А найти нормального заказчика очень сложно, тем более, что сейчас сытое время кончилось.
Студенты работающие за еду в конечном итоге становятся нормальными программистами:)
Даже в сытное — живут не слишком.
У большинства заказчиков тривиально заканчиваются деньги 🙂
Конечно в моменты, когда инвесторы раскидывают деньги направо и налево — то могут и выжить.
Еще есть гос заказы 😉
Это типичное поведение студента с первыми клиентами. Также называется «юношеский максимализм». Так набиваются первые шишки и без них никак.
На самом деле, я скорее хотел внимание на клиенте сконцентрировать, а не на исполнителе (хотя он тоже хорош).
Тут еще важно посмотреть на ситуацию с точки зрения исполнителя. Перед началом работы обязательно надо требовать ТЗ и срок и стоимость работы назначать исходя из обговоренного и утвержденного заказчиком ТЗ. И если потом начинаются танцы с «сделать покрасивее», добавить автоинсталляцию и т.п. — надо это жестко пресекать или поднимать стоимость и срок разработки.
Т.е. в описываемой ситуации оба виноваты. Зачастую исполнителю гораздо выгоднее отказаться от работы даже на этапе когда уже почти все готово, чем бесплатно работать еще две недели, реализуя неожиданно возникающиющие идеи заказчика.
Опять же, если у исполнителя есть определенные требования, это и заказчика дисциплинирует.
К сожалению не всегда заказчик понимает что он хочет, и поэтому тз, сроки и стоимость определить нереально. Да и ТЗ далеко не панацея, вот например лет 5 назад у нас был заказчик из криминала. И когда он нам сказал что мы будем работать на него бесплатно, мы с большим трудом нашли адекватный ответ:)
Поэтому с заказчиком надо договариваться, а по результатам уточнений требований ВСЕГДА вести протокол, под роспись обоих сторон. А потом и можно и показать всю сложность проекта.
p/s
Кстати недавно один опытный фрилансер сказал что он всегда закладывает в цену изменение требований заказчика, причем у него есть предел: не более 25 процентов от сроков работ.
Чуть выше уже написал, что я даже пытался больше сконцентрировать внимание на заказчике, а не на исполнителе.
Самое важное, что исполнитель должен понимать и если заказчик неопытный — донести до него, что продукт — это больше чем код.
ТЗ — не всегда выход.
тогда может Agile выход?
В целом, если заказчик неопытный, хоть agile, хоть не agile — проблемы будут.
Как я и написал ключевое, что продукт это больше чем просто код, и гораздо больше чем набор требований.
а как решать такие проблемы?
у нас есть один заказчик — старенький дедушка- всю жизнь в науке. ТЗ он воще не пишет, лично общается с программистами, высыпает все свои идеи, а потом, когда программист к обеду возвращается на свое рабочее место, звонит с новыми идеями )
что делать?
4 чела на него работают, а начинали как мееелкий проектик ))
меня удивляет поведение босса. может я чего-то не знаю.
а как бы ты разрулил эту ситуацию, Виктор?
Если честно, то не хватает данных, для того чтобы выдать какое-то вразумительное решение.
Я бы сказал, есть три направления.
а) Дедушка богат и доволен тем, как все идет.
Пообщался с дедушкой, по поводу планов. Упомянул, что если методы как можно сделать работу более эффективной, но так в вскользь упомянул бы это.
Если заказчик не заметил упоминания — пытался бы ничего особо не менять, нарашивал бы количество программистов работающих над проектом (естественно согласовав с дедушкой).
Может быть эту линию босс и выбрал.
Если заказчик заметил упоминание о эффективности и заинтересовался, то смотри пункт б).
б) Дедушка не слишком богат и уже не слишком доволен.
Предложил бы перейти таки на Agile. Можно (и нужно) не забивать мозги ему тонкостями agile, просто договориться о том, что создается список его идей и пожеланий и он может тасовать как хочет их. Команда всегда работает над самым приоритетным.
И постоянно держать руку на пульсе, что он разумно доволен скоростью продвижения.
в) Дедушка беден и не доволен
Серьезно поговорить с ним и объяснить к чему это может привести. Что при постоянном изменении объема работ, вероятнее всего ничего сделано не будет и в результате он не получит продукт, который хочет и свернет проект.
Дальше, в зависимости, что ему важнее — качество или количество — выбирается agile или waterfall и заказчику бьем по рукам постоянно, как только он начинает вылезать из этого процесса.
Ну и если он не осознает и не соглашается, то посылаем дедушку нафиг.
Тут еще возможен вариант. Не трогаем заказчика и сосем из него деньги, пока можем (возможно этот вариант выбран боссом). Я этот вариант не люблю, так как он заканчивается обычно руганью с заказчиком, задержкой оплат с его стороны, внезапным окончанием проекта (и необходимостью куда-то пристроить 4 программистов).
P.S. Увы, никаких магических рецептов 🙂
Кстати, я ничего не написал насчет продукт vs код в комментарии, так как мне кажется, что проблема у вас с заказчиков пока КАК делать проект. То есть вы не довольны процессом. В тот момент когда процесс более менее становится разумен, таки станет вопрос ЧТО делать.
И вот в этот момент, нужно будет говорить о все остальных вещах (документации, поддержке и т.п.).
То есть, когда будет понятно — пользуем agile, не agile, полное отсутствие процесса, тогда уже стоит внутри этого процесса определяем что и когда будем делать и сколько оно может занять времени/денег.
да, согласен, мой вопрос вышел за рамки темы топика. Кстати на счет темы — вопросов нет) Думаю, что с ростом опыта у проргаммиста, (должен?) меняется его фокус от реализации до продукта.
еще раз спасибо за ответ.
Пожалуйста. Надеюсь ответ пригодиться 🙂
Насчет фокуса программиста. По разному бывает. У программистов все таки по разному устроены мозги — одному хочется копаться только в технических деталях, другому — видеть весь продукт целиком. Вторые редко в программистах остаются.
Дальше, в зависимости, что ему важнее — качество или количество — выбирается agile или waterfall
Да почему ж одни маргинальные методы на выбор-то?
Они ж обе зацикливаются. Водопад — на анализе, agile-«наживулька» — на кодировании.
http://arbinada.com/main/taxonomy/term/79
Естественно, можно выбрать и что-то другое.
Кстати, я не совсем согласен с тем, что agile — это зацикливание только на кодировании. Согласен, что внимание таки перенесено на него с анализа. Но все же, как я понимаю освновная цель постоянно иметь что-то жизнеспособное (так что, да, таки «наживулька»). Но вот каким образом будет это жизнеспособное делаться — это уже второй вопрос.
А надо ли постоянно иметь нечто сделанное на живульку? Это по большому счету вопрос дисциплины и стандартов самого заказчика равно как и доверия между заказчиком и исполнителем. Свой отдел ИТ — куда ни шло. А если его нет, все исполнители внешние?
Предположим, у заказчика 2 среды: тестовая и продуктовая. К тестам привлекаются ключевые пользователи. Перенос из одной в другую строго регламентирован. Можно ли в таких случаях уповать на частые релизы вместо проработки требований к системе, функционала и четкой фиксации того, что будет сделано и что надо будет тестировать?
Да, естественно, в конечном счете все сводится к необходимость заказчика.
Писать софт для космических кораблей в agile стиле никак не выйдет, что с внешним, что в внутренним IT отделом.
Делать какой-то внутренний не слишком критичный продукт — agile то, что нужно.
Приведенный пример с двумя средами не из космической отрасли, а из внутреннего проекта некритичного к простою приложения для заказчика — крупного дистрибутора. Вопрос внутренних стандартов и качества управления.
Криминальный заказчик, это все-таки отдельный разговор. И для фрилансера, например, почти нереальная ситуация — очень трудно наехать на виртуального исполнителя.
В целом, я с вами согласен. Просто хотел высказать мысль, что если иметь свой собственный кодекс и стараться ему следовать, то большая часть проблем отпадает сама собой.
Я, например, не прогибаюсь в части условий оплаты. Они у меня довольно жестко зафиксированы. И заказчик еще до обсуждения работы знает эти условия, поэтому попытки навязать свои бывают довольно редко. А мне служат сигналом, что что-то с заказчиком не так.
Отклонения, конечно, всегда бывают, но они только подтверждают правила.
Кстати, ТЗ с заказчиком всегда надо обсуждать, прежде чем что-то делать. Более того, надо всегда спрашивать, зачем ему нужно то, то и то. Потому как заказчик может не иметь понятия о возможностях, желать странного или просто иметь неправильные представления о предмете. В конце концов, ему нужен конечный продукт, но часто заказчик пытается описать не сам продукт, а как он должен быть реализован. И тут все зависит от его опыта и знаний.
Свой Кодекс это хорошо:)
А с ТЗ все-же надо аккуратнее, не каждый Заказчик поймет умные слова в ТЗ. Бывает что некоторые Разработчики составят ТЗ, а Заказчик чтобы не выглядеть глупым его подпишет. Понятные слова надо использовать:)
ТЗ вообще штука сложна. Это хорошо, когда заказчик знает до последней пиндюрки, что он хочет в продукте. Чаще всего это не так и это вполне обосновано.
Хотя безусловно, на фиксированную оплату имеет смысл соглашаться только с фиксированным размером работы.
Кстати, я поэтому не слишком влюблен в идею фиксированной оплаты. хотя безусловно у нее есть свои положительные стороны.
Фиксированной оплаты с фиксированным объемом работ практически не существует 🙂 Правильнее сказать, что есть работа в рамках бюджета, с заданным объемом работ.
Ну, это уже просто разница формулировки. Смысл один и тот же. 😉
Позволил себе взглянуть на ситуацию с другой стороны: Давайте жить дружно или каждому свое 🙂
Интересно 🙂
Единственное, я бы не был так катигоричен, что заказчики и исполнители друг друга никогда не поймут. Понять вполне можно. Но понять — это не значит найти взаимовыгодные условия.
Так большой интегратор может вполне понимать маленького заказчика, но при этом даже понимая, они не смогут сойтись в условия работы, просто потому, что они заточены на разные ниши.
Кстати, если не секрет, что конкретно было сказано, чтобы успокоить этого самого криминального заказчика. (Честно говоря от описанной ситуации — бросает в холодный пот).
Под пониманием понимается и поиск точек соприкосновения, важен ведь результат?:)
p/s
А для криминала был найден человек, который смог им объяснить что не стоит наезжать на этих ребят. Правда его власти не хватило чтобы деньги вернуть:( За данную помощь мы конечно потом тоже рассчитались, своей работой за еду:)
>Под пониманием понимается и поиск точек соприкосновения, важен ведь результат?:)
Под пониманием понимается, то что знаешь почему человек ведет себя так или иначе.
Так что понимае — одна из вещей необходимых для поиска точек соприкосновения, но не единственная.
Да, в бизнесе — действительно важен результат.
Витя, а ты в этой истории был заказчиком или исполнителем?
Как-то оба персонажа выглядят неприглядно 🙂
До боли знакомая ситуация, когда заказывал небольшую прогу на линчекер. Все было с моей стороны — и ТЗ (полное) и предоплата. Итог — 3 месяца разработок вместо 2 недель. ТЗ не всегда помогает — смотреть нужно на адекватность исполнителя.
Ну, кстати я не только о исполнители но и о заказчике говорил.
Да, ТЗ — вещь хоть полезная но не панацея.
Полезно иногда взять MS Project и все этапы/задачи поставить последовательно (я говорю об Исполнителе сейчас). У меня есть скелет типового ИТ-проекта, куда включено и согласование ТЗ и подписание договора и разработка с тестированием и написанием документации. Есть там еще и сдача-приемка с доработкой и промежуточными демонстрациями.
Все эти этапы будут всегда, причем, по собственному опыту, на одну задачу, сколько бы часов фактической работы она не занимала, календарно будет выходить минимум 1 день (мой минимальный estimate для элементарных задач).
Если в ТЗ вложить такой проект, например, в виде диаграммы Гантта, взаимопонимание между Исполнителем и Заказчиком может улучшиться. Оттуда будет видно как получаются такие сроки и откуда берется стоимость, и почему хотя там фактической работы на два дня, проект длится 2 недели (сразу вылезут выходные, время на задержки с утверждением документов, feedback и т.д.).
Кстати, такой план проекта полезно иметь именно исполнителю, чтобы элементарно не попросить меньше денег. И Заказчик, видя, каким образом задачи учитываются в плане проекта может примерно прикинуть сколько будет ему стоить (в деньгах и времени) новая функция и как она повлияет (по деньгам и времени) на остальные.
P.S.
A new version of WordPress is available! Please notify the site administrator.
В целом все верно. Кстати, сам в свое время имел документ с шаблоном estimat’а, чтобы не забывать все дополнительные задачи.
Но есть много «НО».
— заказчики частенько просто недостаточно знающи, чтобы воспринять хорошо детальный подход
— не всегда проект хорошо планируется вперед на длинный срок, так как неизвестно заранее что нужно сделать. И чаще всего по ходу оно меняется (по этому я люблю Scrum)
P.S. Эххх. Переставлять самому — времени куча займет, так как дорабатывал ручками разные куски. Нанять кого-то это сделать — выйдет дорого (дороже того, что я хочу потратить на этот блог в виде денег).
Давольно смешной матерьял особенно про то что уже в видовс встроееный есть , а так все написано в шутливой манере но с огромным смыслом , так как производитель ведет себя так в 70 % случаях всегда что то не то , и в итоге затраты превышают доходы и производитель терпит крах .
Эта тема вечна. Вот «Примерный сценарий внедрения информационной системы» написанный давно, совершенно но в том же стиле.
http://www.arbinada.com/main/node/71
Забавно 🙂 Я этого не видел. Но действительно — даже стиль тот же 🙂
И увы тема действительно вечная. Точнее… До тех пор пока IT будет приносить высокие прибыли, в IT будут лезть малоопытные заказчики. Как только IT станет по прибыльности эквивалентна другим областям, количество таких заказчиков резко упадет.
Да, с такими клиентами лучше дела не иметь, и вообще, следует условия и масштабы работы от и до оговаривать предварительно! 🙂
Почти согласен с Victor Ronin. Перестанут лезть не только заказчики, но и исполнители. Щас розвелось таких, только бабулек-пенсионеров стращать умеют и умное лицо делать 🙂
если поэтапно всё планировать всё должно получится без проблем
как говорится «семь раз отмерь-один раз отрежь»
Это такая ситуация в реале была? Перед тем как заказывать у кого-то работу, нужно изложить исполнителю все нюансы по поводу того, как должна выглядеть эта работа
Ну, зачастую заказчик сам и не знает все нюансы.
Сейчас свой продукт веду. И месяца 3 назад мое представление о нем было откровенно смутным. Плюс опять, же то, что я и говорил — даже описал все детали связанные с реализацией, получиться только код, а не продукт.
Заказчик должен определить для себя, что ему нужно и изложить это в устной или письменной форме исполнителю
Надо определиться что хочет покупатель, заранее договариваться и обговаривать все пункты, чем занимается работник, понятно без этого никуда