Pull to refresh

Comments 55

Думается, это зависит от каждого конкретного заказчика. Иногда человек точно знает что он хочет видеть на своём проекте и готов за это платить даже в том случае, если со временем это выльется в раковину (т.к. он просто не видит последствий). Когда же такое происходит он хочет просто переделать свою идею и опять за это платит, т.к. видит что именно его мысль привела к таким последствиям.

Таких людей тоже довольно много. Особенно если они не полные профаны, а хотя бы немного разбираются в вебе хотя бы на уровне пользователей и имеют представление о юзабилити. Конечно, можно предупредить такого клиента о том, что его идея может иметь печальные последствия. Но всегда ли это нужно, если он платит?
У меня в последнее время стало слишком много проектов, в которых основная часть работы не конструктивного характера, а тупая ликвидация последствий.

Менеджеры придерживаются такой же точки зрения — «что угодно за деньги заказчика», мне же как разработчику гораздо приятнее делать что-то новое и хорошее, ведь за это тоже платят. При этом хоть какое-то движение вперед и в портфолио мог бы быть не один посредственный, три раза переделанный проект, а три хороших.
У меня тоже подобная проблема — в основном переделывание нескольких старых проектов под изменяющиеся требования. Но для меня всегда интересно реализовать лучше, чем было, добавляя новые возможности, которые просит сделать заказчик и применяя там новые технологии.

Даже ликвидация последствий бывает приятной, когда видишь, что проект начинает работать стабильнее и отношение заказчика также меняется, т.к. там есть всё, что он хочет и работать это всё начинает как надо. Но, конечно, соглашусь с вами, что намного приятнее создавать, чем исправлять.
если есть ТЗ то таких проблем просто не будет возникать
а все «доделки» будут уже идти как поддержка проекта за отдельные деньги
1. Почему старое не может быть хорошим?
2. Почему бы не сменить менеджера или как попытаться согласовать с ним действия, вмешаться в процесс? Среди заказчиков, вопреки распространенному мнению, дофига толковых и адекватных людей. Беда в том, что они не умеют говорить на языке разработчиков, а мысли, изложенные на их собственном языке, часто не бывают услышаны. Связующее звено, менеджеры, не всегда хотят понимать что стоит за сухими словами в заполненной заказчиком анкете.
Да, часто встречается непрофессиональный подход к управлению проектом. Так сказать, поверхностный, когда менеджер не вникает и не понимает мысль заказчика и соответственно не будет с ним на одной волне.

Почему бы не сменить менеджера или как попытаться согласовать с ним действия, вмешаться в процесс?

Не каждый программист может сменить менеджера проекта =)). А если серьёзно, то согласовать свою работу с менеджером не всегда просто (данная конфликтная ситуация была в моём личном опыте). Часто слышишь ответ — не лезь не в свою работу. Поэтому сейчас работаю без менеджера и предельно счастлив. =))
Даже при хороших взаимоотношения бывают тёрки и конфликты, это нормально. Но если тёрки и конфликты — это тренд™, то искренне не понимаю, зачем продолжать плакать и жрать кактус :)
Главное, чтобы было как в «Крёстном отце»: ничего личного, только бизнес. =)) А то иногда очень противно, когда в компании начинаются личные разборки из-за чисто деловой активности…
мне всегда казалось (во всяком случае в ситуации фриланса точно) что разработчик должен быть и менеджером
мысли верные, но иногда заказчик начинает вопить «я не так просил!» приходиться делать как просил он и переделывать, если повезет за его счет. Отсюда вывод четкое ТЗ спасет мир.
На «четкое ТЗ» уходит огромная куча времени. Как по мне, так его лучше потратить на то, чтобы научиться отличать адекватных заказчиков ;)
Адекватные заказчики, это которые сами для себя напишут за вас ТЗ разобравшись в вашем потоке мыслей?
ИМХО, подход неверный.
1. Под адекватными заказчиками я подразумевал тех, с которыми можно установить нормальное понимание проблемы (все знают, что в случае с «проблемными» заказчиками и ТЗ не всегда помогает) и риск быть «кинутыми» в итоге будет сведен на нет.
2. Под «четким» ТЗ лично я сам понял эдакий документ страниц на 150 (к примеру), точно описывающий конечный результат. Нередко, время создания подобного документа может быть аналогичным времени создания самого продукта. ИМХО, ТЗ нужно обязательно, но только для того, чтобы обозначить рамки.
считаю, что ТЗ вообще не должно напрямую быть связанным с клиентом. это внутренний документ, для разработчиков. если клиент мне начинает присылать документы с названием «Техническое задание» — это сразу клиника и нужно пресекать такие вещи, иначе приходится многое потом разгребать и переделывать, согласившись на «ТЗ» клиента. пример, если говорить о сайтах: какая-нибудь секретарша клиента набрасывает прототип страниц сайта, пишет что где и как должно работать.

все, что нужно от клиента — постановка задачи проекта, описание целей. техническая сторона — не их забота.

исключения: если я работаю как субподрядчик через других специалистов либо если курирующее лицо со стороны клиента — также специалист.
Но насчет «я не так просил!» полностью согласен. Везде и постоянно такое встречается.
Начало не плохое. Середина поста предсказуема. Окончание банально =)
Имхо, это и так все ясно. Заказчику нельзя давать понять, что место на ваших плечах свободно, иначе он тупо сядит вам на шею =(.
Не, это другой вопрос. Но на этапе согласования ТЗ как лучше поступать, отстаивать свое мнение с самого начала? Или как предлагают выше, делать как хотят, если платят, и потом, если заплатят, переделывать?

Когда у меня есть возможность, если не получается убедить, стараюсь отказаться, но не делать лажу даже за хорошие деньги.
Скорее всего возможно модифицировать идею заказчика, чтобы она его продолжала устраивать и казалась ему его. Но в тоже время перестала быть лажей в реализации.
Не стоит путать цели заказчикаи варианты достижения этих целей.
По первому пункту, как правило, заказчики бывают правы, и смотрят они зачастую более стратегически выгодно, нежели разработчики.

Но вот почему не стоит сразу делать все, что они пожелают — этого я не поняла. В рамках определенной стратегии — даназдоровье, создание сайта при участии грамотной команды — это чуточку более нетривиальный процесс, нежели приготовление кофе руками несмышленого малыша ;)

Прощу прощения за курсив, с тегом промахнулась.
как правило, заказчики бывают правы, и смотрят они зачастую более стратегически выгодно, нежели разработчики.

Они смотрят стратегически выгодно для своего бизнеса, но не понимают, что решения, которые они принимают при развитии продукта, могут быть противоречивыми с точки зрения архитектуры. Это довольно большая проблема для динамически развивающегося приложения.
Так они и не должны понимать, им важно достичь некой бизнес-цели, им пофик на архитектуру, производительность, рюшечки и всякие другие столь милые сердцу разработчика штуки. «Знал бы прикуп, жил бы Сочи», как говорится. Это задача разработчика — предложить решение, которые сумеет удовлетворить заказчика и учесть технические ограничения, это его работа.
Это задача разработчика — предложить решение, которые сумеет удовлетворить заказчика и учесть технические ограничения, это его работа.

Про это я писал выше. Но хочу отметить, что имея проект на долгой поддержке, когда требования с развитием меняются настолько кардинально, что стартовая модель перестаёт работать, становится очень сложно адаптировать требования заказчика. Поэтому цели заказчика следует направлять в необходимое русло в таких случаях, а просто удовлетворить его уже не получится.
А мне кажется, что отход от первоначальной модели при развитии проекта — это нормально. В этом контексте хочется согласиться с автором — «не всё сразу», но придерживаться текущих и будущих целей и задач заказчика стоит всё-таки в большей степени, нежели глядеть в прошлое.
Это очень страшно, когда происходит именно отход от модели. Когда модель трансформируется — это нормально. Зачастую отход — это просто прикрепление к ней сбоку дополнительных функций, т.к. они нужны. Но как они будут взаимодействовать с моделью — уже не так важно в этом случае.
А что вы подразумеваете под моделью?
Техническое описание бизнес-модели — UML, XMI и т.п. Кому что по душе.
на моем попечении двое подростков-переростков, так что имею шанс насладится созерцанием модели отношений основанной на гармонах…

что делают с человеком эти химические звери? правильно — заставляют чего то сильно хотеть. Временами до отключки здравого смысла (кто прожил свои 15-16-17 лет тот поймет :-))

деньги (особенно при их нехватке) тоже заставляют сильно хотеть… И вот картина:

Одна сторона под действием гормонов (жажды денег, давлением сроков), обычно это разработчик очень хочет РАЗВЯЗКУ СЕЙЧАС, другая сторона, которая дает (в данном случае деньги)… понимает, что после РАЗВЯЗКИ уже ничего не получит… и хочет РАЗВЯЗКУ потом а пока немного ______нужное вписать_____.

Ну вот так они и живут… aha

В общем, если отбросить в сторону всю эту мишуру типа ТЗ, то суть подобных ситуаций просто в игре под названием «делаем сайт»… поймете игру — получите выгоду от всех возможных итераций и переделок…

Помоему надо было положить сахар. Я вот если кладу больше кофе, то кладу и больше сахара.
Не, просто кофе надо варить, а не заваривать в чашке.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Не менее важно все-таки убедить заказчика, что это — действительно вкусно, тогда он точно будет пить с удовольствием, что бы вы там ему ни набадяжили =))
Клиент всегда прав.
Если вы не согласны с этим, просто откажитесь от заказа.
Отличное сравнение. Жаль не всякому заказчику его приведешь. Обидеться могут :)
Клиент действительно платит и поэтому формально имеет право требовать. Но увы, часто самодурство Клиента вредит процессу. Потому что даже если «главному бухгалтеру Марье Ивановне» очень нравятся розовенькие цветочки, то это совершенно не значит, что они должны быть на сайте. Особенно когда тематика совершенно другая. Иначе зачем вообще приглашать стороннего специалиста, раз сами всё знаете и советы не нужны?

И в таких ситуациях у меня лично всегда наступает внутренний конфликт чистолюбия и жажды денег: сделать хорошо или плюнуть на всё, нарисовать «розовенькие цветочки», забрать деньги и забыть? (убрать авторские метки, исключить из портфолио и т.д.)

Говорят, что, мол, «Не нравится — отказывайтесь» как правило почему-то те, кто сам в реальности с подобным нос к носу не сталкивался.
«Говорят, что, мол, «Не нравится — отказывайтесь» как правило почему-то те, кто сам в реальности с подобным нос к носу не сталкивался»

С опытом приходит понимание, что лучше отказаться, так выдет дешевле. Можно 3 месяца править, при этом удовольствия от раоты нет, результат в минусе, в портфель не поставишь, времени упущено куча, нервов потрачено тонна.
Что верно, то верно. Опытный менеджер проблемных Клиентов издалека видит. Вот только иначе как через опыт проб и ошибок этому не научиться.
Мне понравилось сравнение. Почти притча.
Да-да… чуть-чуть переработать в стиле «Юный ниндзя долго наблюдал за доном Игуаном и однажды решил сам заварить себе пейотль. Но вместо индульгирования нагваля с ним чуть было не случилась разинвольтация эгрегора. „Почему так?“ — спросил он горного аксакала. Вместо ответа мастер дзен огрел его бамбуковой палкой. Ибо нефиг переводить пейотль.»
Верно-верно.
Заказчики не спецы в деле, они не могут требовать действительно хороших вещей, они думают не как спецы.
Был показательный пример. Заказчик предложил свой дизайн, который он сделал сам. А потом сказал, что сайт скучный, сразу ясно, почему :D
Вы верно подметили: «Однажды, когда я только начал доставать до верхнего шкафчика...», а заказчики ведь бывают и из рязряда «мам».

А бывает и так, что исполнитель мнит из себя, а когда валит сроки и проект, начинает гнать на некомпетенцию клиента.

По-моему важно изначально понимать с кем работаешь и важно, чтобы ожидания были оправданы будь-то ваш заказчик «мама» или «ребёнок», а для этого они(ожидания) должны быть как минимум ясны обеим сторонам.
ЧЕТКОЕ, подробное ТЗ и четкие сроки в договоре — решение проблемы в 99% случаев.
Если составить такое ТЗ, то исполнителю ловольно просто уложиться в сроки, так как он может оценить объемы работ по ТЗ, все прикинуть, продумать и согласиться на сроки которых требует заказчик или же сказать ему что это нереально для него при таком объеме работ.

Все это, палка о двух концах:
1. Заказчики часто ленятся или не хотят платить за специалиста который составит хорошее ТЗ =>
2. Исполнители устали от слишком частого невежества заказчиков =>
3. Исполнители привыкают к неадекватным заказчикам и сами становятся неадекватными и теперь нормальному заказчику с исполнителем тяжело
4. Как итог постоянные споры и обсуждения подобные этому.

От себя лишь скажу что виноваты оба и изменить ситуацию проще всего изменив себя.
По этому поводу хорошо сказал один мой знакомый:
«Знаешь, а я никогда не переубеждаю Заказчика, просто делаю как он хочет
а спустя время, когда он понимает, что сделано не так, дорабатываю за отдельную оплату.»

и в этом что-то есть, правда
(хотя я лично придерживаюсь другого взгляда, поскольку это может сильно подпортить имидж
что на рынке рекламы чревато)
Никогда не надо забывать, что в собственных бизнес-процессах заказчик разбирается куда лучше нас, исполнителей. Очень часто идеи заказчика опираются именно на его знания о потребностях его клиентов. Так что иногда следует прислушиватся к тому, что просит/предлагает/требует клиент. Без фанатизма, разумеется.
Притча про заказчика, который сам решил сделать сайт.
вам надо в выхлопы, и ваша мысль не соответствует логике притчи (имхо), капитан Очевидность)
Один в один с мультфильмом про собачку Соню и горчицу
Фигню написали!

«В этом нет смысла!».

История ваша о том, что вам в детстве не давали кофе, а тут попробовали его, и обожглись по незнанию — вот о чём эта история. А заказчик здесь примешан задним местом лишь для того, чтобы АйТи история. И уж тем более она не для блога «Учись Работать».

Может завтра я буду вашим заказчиком, а я люблю кофе с 6-ю ложками!
Наш кофе в два раза крепче вашего, а при использовании нашей техники для получения кофе одинаковой крепости с аналогом нужно на 34% меньше сырья.

Будете настаивать на кофе с 6-ю ложками или все-таки подумаем и сформулируем как-то иначе?
У меня тоже есть воспоминание детства. Я очень любил какао, и однажды подметил, что какао-порошок хранится в шкафу, в горшочке. Я достал горшочек, облизал палец, макнул его в порошок и облизал. Всё бы здорово, вот только в горшочке было не какао, а красный перец.
Sign up to leave a comment.

Articles