На что ориентируется заказчик при выборе студии веб-разработки?

[Ivan Ukhov]

Добрый день!

Провожу исследование на тему <<На что ориентируется заказчик при выборе
студии веб-разработки>>, интересует уклон в сторону нестандартных
решений. Прошу по возможности принять участие и написать, какие
факторы по вашему мнению являются наиболее востребованными, опираясь
на ваш профессиональный опыт работы с клиентами. Приведите,
пожалуйста, несколько факторов, не больше десяти, в порядке уменьшения
их степени значимости.

Обещаю поделиться результатами исследования.

Большое спасибо за помощь!

С уважением,
Иван.

[Danil Pismenny]

1. Наличие, качество и количество ранее реализованных проектов.
2. Способность ловить идею/мысль и продлить ее без муторного описания
подробностей в ТЗ.

[Maxim Filatov]

On Oct 1, 2010, at 3:30 PM, Danil Pismenny wrote:

> 2. Способность ловить идею/мысль и продлить ее без муторного описания
> подробностей в ТЗ.

Прекраааасная мысль...
А потом будет муторная, многолетняя борьба с заказчиком, из-за того, что ТЗ не было.
Спасибо, это мы уже ели.


---
Best regards,
Maxim Filatov

[Eugene Hlyzov]

Все зависит от типа проекта. Иногда заказчик в принципе не может четко определить чего он хочет - например, он не знает, как отреагирует пользователь на ту или иную фишку. И в этих условиях навык работать без ТЗ - это важно. И заказчик действительно будет искать людей, способных "поймать" идею.

[Alexander Pavlyut]

Внесу 5 копеек.

Как то я поднимал тут вопрос в группе как же можно генерировать scaffold'ы применяя при этом i18n чтобы без тз можно было прямо на лету изменять большой кусок приложения только для того чтобы заказчик мог "посмотреть" - то/не то.

В результате догой е*ли вывод просто укоренился в моей голове и я просто выпульнул сюда жизненный баян:

"Если заказчик не может написать тз - найди возможность надавить чтобы он написал тз, или же пиши тз сам но не начинай работать без тз, или вообще попрощайся с заказчиком который не может сформулировать что же он хочет".

Я не прав?

> --
> --
> Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
> FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
>
> Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
> ror...@googlegroups.com
> Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-un...@googlegroups.com
> Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru

[Maxim Filatov]

On Oct 1, 2010, at 3:55 PM, Alexander Pavlyut wrote:

> "Если заказчик не может написать тз - найди возможность надавить чтобы он написал тз, или же пиши тз сам но не начинай работать без тз, или вообще попрощайся с заказчиком который не может сформулировать что же он хочет".
>

плюс стопиццот

Если человек не знает, чего хочешь, то чего ты там ему не делай - счастья не будет.

[Андрей Огневский]

Начинать работать без ТЗ — зло, безусловно. Просто, возможно, не стоит требовать от заказчика мега-супер-издания-на-200-страницах, а простым языком понять, чего он хочет, записать это на бумаге, нарисовать макеты, наброски, показать как можно, посоветовать как лучше и тд. В общем, все в духе Getting Real. 

Я и свои мысли для себя самого не могу четко сформулировать, это значит только то, что нужно сесть, спокойно все обдумать и в итоге понять, чего же мне хочется.

Нарисовать макет на бумаге — 5 минут, в браузере при помощи 960gs или blueprint css — максимум полчаса—час. 

Но, понятное дело, всегда есть исключения из правил.

Для меня первостепенным фактором является не «звездность», а «человечность», не только в it-мире, но и по жизни.

2010/10/1 Alexander Pavlyut <apav...@gmail.com>

[Eugene Hlyzov]

У нас как-то был заказчик, который отсутствием спек на задачи и долгими корректировками по ходу выполнения задачи всех достал. В случае, когда ты просто исполнитель и твоя задача - предоставить формальные доказательства твоего права на деньги, тогда ТЗ - это основной документ для решения споров и для обоснования доп. затрат.

Но следуя приведенному жизненному баяну отсеивается важная (на мой взгляд) группа заказчиков. А именно те, кому не хватает технической грамотности и уверенности в рынке для составления ТЗ. Допустим, высокорисковый стартап. ТЗ там может меняться каждую неделю - т.к. очень сложно предсказать какое из направлений проекта окажется предпочтительным. Частое взаимодействие заказчика и исполнителя в этом случае может оказаться весьма успешно и вполне заменить ТЗ.

В общем, основная моя мысль была о том, что существуют проекты, в которых странно требовать от заказчика ТЗ. Конечно, если ты не хочешь "просто получить деньги", а хочешь вложить силы во что-то работающее. Тем не менее, если отношения исключительно [ очередной заказчик ] <-> [ очередной исполнитель ] и вся аналитика находится на стороне заказчика, тогда да => ТЗ -> estimate -> [whatever] -> ПРОФИТ.

[Alexander Pavlyut]

Ну читайте же между строк.

Никто не говорит что надо закрыться в будку и посылать всех в задницу без тз.

Правильная формулировка - не приступать к работе без тз, как минимум по двум причинам:

1. Это отличный roadmap для тебя и заказчика, по которому можно сверится что сделано а что нет и не будет споров.
2. Это отличное подспорье для тебя как "план действий" или проще "что делать надо".

Если заказчик не сильно способен составить тз - помоги ему, составьте вместе.

Или если вы прекрасно друг друга понимаете с полуслова - зафиксируйте ваше понимание на бумаге, она стерпит.

И дальше по плану - приступать к работе только при наличие тз.

Вроде все просто же.

[Yaroslav Markin]

2010/10/1 Maxim Filatov <pipo...@gmail.com>

On Oct 1, 2010, at 3:30 PM, Danil Pismenny wrote:

> 2. Способность ловить идею/мысль и продлить ее без муторного описания
> подробностей в ТЗ.

Прекраааасная мысль...
А потом будет муторная, многолетняя борьба с заказчиком, из-за того, что ТЗ не было.
Спасибо, это мы уже ели.

Работать нельзя не без ТЗ, а без контракта — разница большая, согласитесь. Состав приложения к контракту, в котором описывается функционал и его формат — вопрос отдельный.

Спецификацию на проект из нашего опыта (evilmartians.com) всегда приходится писать самим, даже если техспециалисты заказчика что-то уже составили — в этом ничего зазорного нет. Мы обычно пытаемся собрать требования и понять концепцию на пресейле (бесплатно, во время встреч с заказчиком), а спецификацию пишем уже на возмездной основе — или когда начинаем работать над первым релизом, или только спецификацию без разработки — если заказчик еще не решил, что проект нужно делать / нужно делать с нами.

Состав спецификации должен быть ровно такой, чтобы заказчик был с ним полностью согласен, интерфейсники могли начать работу с минимальным количеством вопросов, а сценарии/use cases — достаточно подробными, чтобы разработчики брали их в разработку «как есть». Юридически исполнитель делает именно то, что написано в контракте — минимальный набор функционала. Чтобы заказчика не «штормило» со внесением изменений в спецификацию, полезно перед всей работой составить (и подписать) концепцию — что заказчик хочет от проекта и каким образом (1-2 страницы, обычно). После релиза (несколько итераций) все повторяется — новая часть спецификации, новый контракт.

Бывают проекты с очень, очень частыми релизами и частыми изменениями — в таком случае проще подписывать контракт с минимальной спецификацией, а требования добивать по ходу — прописывать все в тасках Basecamp, делать вики, что угодно. Если заказчик не может работать в таких условиях или проявляет неадекватность — всегда можно «соскочить».

Еще можно подписывать контракты на time/material (мы даем вам команду, которая делает все, что нужно) — работает, если заказчику очень нужен функционал к сроку, а гарантии дать сложно («сделайте что сможете»). В России, правда, такое подписывать не очень любят.

--
Yaroslav
http://evilmartians.com/

[Ivan Ukhov]

Возвращаясь ближе к теме), вот какие ответы я еще получил:

1. Отзывы знакомых (если кто-то из знакомых уже делал что-то подобное
и ему понравилось, то первым делом обращусь туда)
2. Отзывы в других местах (в комментариях к статьям, самих статьях --
именно в таком порядке и т.п.)
3. Надежность компании (в плане качества, сроков и т.п) -- опять же
можно судить только по отзывам или по авторитету компании (не знаю
откуда он берется, но думаю у Лебедева, например, делают все хорошо)
4. Делали ли уже что-то подобное
5. Стоимость
6. Общая адекватность людей, схожесть во взглядах на конечный
результат, процесс разработки и т.п

1) Портфолио
2) Сайт Веб-студии(визуальные эффекты, красота оформления, отсутствия
лагов)
3) Сроки выполнения работы
4) Представительность сотрудников(внешний вид и прочее)
5) Контакты:
а) наличие короткого номера, номер не Теле2;
б) Почтовый ящик должен быть на собственном домене(не
com...@mail.ru и другие почтовые сервисы)
6) Гибкость при общении

А какой список у вас?)

[anahoret]

Судя по количеству проектов которые приходится делать после индусов
заказчик в первую очередь ориентируется по цене в первый раз а потом
по отзывам и портфолио :)
Человечность обеспечивает sales manager во время получения проекта и
менеджером после :)

Вообще на разных рынках приоритеты разные. Попробую об этом рассказать
на RubyConfUa 2010

On Oct 2, 12:03 am, Ivan Ukhov <uvs...@gmail.com> wrote:
> Возвращаясь ближе к теме), вот какие ответы я еще получил:
>
> 1. Отзывы знакомых (если кто-то из знакомых уже делал что-то подобное
> и ему понравилось, то первым делом обращусь туда)
> 2. Отзывы в других местах (в комментариях к статьям, самих статьях --
> именно в таком порядке и т.п.)
> 3. Надежность компании (в плане качества, сроков и т.п) -- опять же
> можно судить только по отзывам или по авторитету компании (не знаю
> откуда он берется, но думаю у Лебедева, например, делают все хорошо)
> 4. Делали ли уже что-то подобное
> 5. Стоимость
> 6. Общая адекватность людей, схожесть во взглядах на конечный
> результат, процесс разработки и т.п
>
> 1) Портфолио
> 2) Сайт Веб-студии(визуальные эффекты, красота оформления, отсутствия
> лагов)
> 3) Сроки выполнения работы
> 4) Представительность сотрудников(внешний вид и прочее)
> 5) Контакты:
>     а) наличие короткого номера, номер не Теле2;
>     б) Почтовый ящик должен быть на собственном домене(не

> comp...@mail.ru и другие почтовые сервисы)

[Ivan Ukhov]

"
1. Опыт (наличие аналогичных по уровню работ в портфолио).
2. Рекомендации (наличие серьезных компаний в числе клиентов студий).
3. Возможность долгосрочного сотрудничества (расширения возможностей и
поддержка).
4. Приемлемость цен (адекватная ценовая политика).
5. Гибкость (отсутствие слишком жестких условий, готовность идти на
компромисс, доброжелательность).
6. Актуальность и распространенность технологий.
7. Энтузиазм и ответственность.
"

On Sep 29, 12:14 pm, Ivan Ukhov <uvs...@gmail.com> wrote: