Pull to refresh

Comments 45

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

С заказчиком очень полезно изначально обсудить терминологию.
Если это делать сразу, то к вашем вопросам отнесутся лояльно и с пониманием, вы же новичок в их деле.
Именно, хотел написать тоже самое.
Категорически важно если не создать отдельный документ, то хотя бы в ТехЗадании сделать раздел «Термины и определения» и в нём как можно более детально прописать все те термины, которыми вы оперируете при разговоре с заказчиком.
И еще очень правильно подмечено, что беседовать надо не только с руководителем, а крайне важно добиться возможности побеседовать с теми, кто будет внедрять и эксплуатировать ваш продукт, ибо могут выясниться «важные интимные подробности», способные поставить весь проект с ног на голову.
Поделюсь маленьким профессиональным секретом.

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

Он демонстрировался всем сотрудникам, и комментарии фиксировались там же.

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

(как аналог — какая-нибудь курсовая по высшей математике; если вы спросите «что такое интеграл» на первом обсуждении — это почти что нормально; если же вы спросите об этом за неделю до сдачи — это, по меньшей мере, глупо).

я всегда стараюсь разузнать все до мельчайших подробностей, и пусть я буду казаться смешным или идиотом.
UFO just landed and posted this here
А перед лицом маятник он не раскачивал при этом? =)
«Κρήτες ἀεί ψεύσται» © Ἐπιμενίδης (:
«Критяне всегда лжецы» © Эпимени́д
Я удивился, что автор не вынес эту цитату в эпиграф к статье, очень уж просится.

Подумалось… у меня есть майка с Хаусом и фразой «Everybody lies»… может надевать её каждый раз на встречу с заказчиком по поводу ТЗ? :-D
Это перевод, а у оригинала нет эпиграфа
Я и говорю, жаль, что «автор не вынес эту цитату в эпиграф» ;-)

А вообще, пользуясь случаем, спасибо за перевод.
UFO just landed and posted this here
Через 2 года выполнения заказов от таких клиентов(долго соображал, да) теперь категорически отказываюст приступать к значимой части заказа до передачи мне четкого ТЗ.
Рекомендую всем триальную версию axure.com — клиенты обычно приходят в восторг и с радостью принимаются за ТЗ :)
Не нужно избавляться… Это же замечательно! Пишете ТЗ. Делаете сайт. Приходят правки? Добавляете их в ТЗ, каждая правка под отдельную стоимость.
UFO just landed and posted this here
Так с самого начала говорите, что изменения в ТЗ будут оплачиваться отдельно. Большая часть это воспринимает совершенно спокойно т.к. уверены что все окей и ничего они менять не будут.
Мы занимаемся разработкой электронного обучения, мультимедийный контент, фактически. Ситуация, когда «ой, ай, в пятом абзаце нужно говорить не 'сервис', а 'техобслуживание', поменяйте», а сценарий уже ушёл диктору на запись — стандартная. В своём первом проекте мы так и погорели — пришлось за свои деньги перезаписывать, потому что это было в итоге дешевле, чем доказывать клиенту, что нехорошо менять согласованный сценарий, который одобрили пять человек, если кто-то из этих пяти решил что-то там дополнить или перефразировать. Все остальные проекты делались и делаются так: сценарий распечатывается, несётся клиенту и физически подписывается на каждой странице. Любая перезапись, пересведение, переделка — по стандартной часовой ставке.
UFO just landed and posted this here
Бывает ситуации еще хуже. Заказчик дает спецификацию на коммерческий продукт на 3-х(!!!) страницах. Понятно, что такую спецификацию нужно уточнять и уточнять. Начинаешь задавать вопросы. Через пять минут выясняется, что на вопросы ответить он не может и взбешен тем, что вынужден это признавать. Начинаются вопли, что ты сам должен решать все вопросы, ты же разработчик, за что мы тебе платим и т.д. и т.п. В конце концов смиряешься, начинаешь что-то сам выдумывать, писать себе ТЗ. Через неделю приходит гневное письмо: где нащ бинари, мы хотим попробовать чего ты там уже написал, потестировать на ранних стадиях, потому-что… дальше упоминаются extreme programming, agile development и т.п. И объяснить, что ты неделю пытался понять что от тебя требуется на самом деле и уже продвинулся в этом невозможно. Ответ один: нам не нужны какие-то схемы и бумажки, что мы, на выставке, которая через неделю (!!!), бумажки что-ли показывать будем? Где наш бинари? За что мы деньги платим? Иногда просто по русски хочется указать направление развития, но низя: для фриленсера терять клиента — вещь не из приятных. Так и живем — от ПМСа до ПМСа.
Отличная метафора :)
Да, только наверное уточнить нужно: от ПМСа одного заказчика, до ПМСа следующего.
какие-то разные у нас с вами заказчики.
Наверно разница начинается в момент «ты сам должен решать все вопросы».

Вообще, конечно, ситуация знакомая, но если вдруг встречается подобное заявление, я обычно отвечаю: «окей, решу», и через полчаса пишу письмо с решением и вопросом «так?».
Заказчик во-первых видит, что работа идёт, во-вторых понимает, что ему не отвертеться от объяснений, и либо придётся подписывать моё решение, либо расписывать и согласовывать своё.

А если уж заказчик не хочет идти на контакт, то потеря такого клиента на ранних стадиях — меньшее зло, чем попытка потом довести дело до победного.
именно так я и делаю. посылаю расклад — так и так, а в ответ: нам не нужны бумажки, где наш бинари?
что, уже через полчаса требуют бинари?

Вам процитировать Станиславского?
А вы обычно тратите полчаса на проработку тз имея лишь небольшой список хотелок? Вам процитировать Станиславского? У меня на это уходит минимум неделя для серьезного проекта.
Я к сожалению (а может и к счастью) не телепат, и не имею вредной привычки додумывать там, где ничего не понимаю.
Если я не понимаю ничего в бизнес-процессах компании клиента, то я не буду тратить неделю на их придумывание.
Говорят «придумывай сама» — да не вопрос, начинаю придумывать. Но каждый даже самый минимальный блок моих придумок отправляется на подтверждение заказчику. А минимальный блок не то что через полчаса, а через минуту может быть готов.
Если заказчик не может дать документ, на основе которого я буду работать неделю, не трогая его, то он начинает получать вопросы сразу и в большом количестве.

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

А если через неделю выясняется, что вопросы никакие не задавались, а исполнитель сделал нечто, ни в коей мере не похожее на то, что нужно заказчику, выдумав всё из собственных фантазий — ну тут уж кто виноват? На мой взгляд очевидно кто.
Честно говоря, тема эта уже поднадоела. Кроме этого заказчика у меня еще 2 постоянных клиента и много однопроектных за пять лет фриленсерства было. Но такая ситуация, которую я описываю, только с одним заказчиком. То, что вы называете «задавать вопрос через пять минут», я называю обсуждением. Как я уже писал неоднократно — на обсуждение человек не идет вообще, считая что я должен всё решить сам. Ну не хочет он вообще разбираться в деталях реализации. Не хочет отвечать на вопросы. Не хочет подтверждать или опровергать правильность догадок моих. И слова «должен подтвердить или изложить собственное видение» только приводят его в бешенство: я ничего не должен, я деньги плачу. Ситуация, по моему опыту, уникальная, и я об этом и писал, что бывает и так. Поверьте, я знаю как разговаривать с клиентами, но люди бывают разные. В конце концов я нахожу даже с этим клиентом общий язык и уже научился сам додумывать за него. Да и он, несмотря на свои комплексы, в конечном итоге доволен моей работой. Но так бывает, и не нужно искать здесь виноватых, скорее нужно как-то взаимодействовать с людьми какими бы они не были.
Ничего, отработаете первый год, дальше сможете выбирать клиентов.
ну вообще-то я уже не первый год в этом бизнесе, о чем писал выше. а с клиентом с этим работаю уже над 7-м проектом. но всё как в первый раз
Тогда ищите проблему в себе. Такой геморрой с клиентами, тем более повторными клиентами — признак непрофессиональной организации процесса. Например, если говорят «додумайте сами», то додумываете, описываете и отдаёте на согласование: «Додумал. Идеи такие. Согласны?», вместо начала разработки с места в карьер.
о какой «разработке с места в карьер» идет речь? я уже несколько раз говорил, что я сначала занимаюсь тз. а вот заказчик желает, чтобы я сразу занимался кодированием. и убедить что так работать невозможно я его не могу уже… то ли 4, то ли 5 лет. Впрочем предложение разойтись мирно — я к новым клиентам, он к новым исполнителям, — тоже не проходит. Вобщем я с этим просто уже смирился — в конце концов деньги платит. Ну есть у него такая фишка (причем это регулярно только раз в год).
Вобщем в жизни иногда бывает не так как в теории — от людей многое зависит тоже.
от людей зависит почти всё :)
В ваших силах объяснить заказчику, как правильно работать.
Вообще то это хороший навык уметь разговаривать с заказчиком «на одном языке» с ним и понимать, что он хочет. У меня есть клиенты, которые приглашают меня на их планерки, только для того что бы я там сидел и иногда служил «переводчиком» между их сотрудниками и начальством. Хотя конечно бывали и забавные случаи. Например, как то раз позвонил мне заказчик попросил внести изменения в программу, причем объяснял, как программа должна работать, при помощи примеров, описывая разные ситуации минут 10, хотя это можно было выразить одним предложением «Нужно, что бы платежки формировались в разрезе назначения платежа». Т.к. я в тот момент был за рулем, я попросил это все оформить письменно и не так путано и прислать мне на почту. На третий день так и не дождавшись письма, я позвонил и уточнил, где ТЗ. На что получил ответ: что мы, мол, нашли выход из положения другим способом. Способ был не очень удобны (даже очень неудобный), но неумение выразить мысль они таким образом скрыли.
Стилистика русский языка несколько отличаться от английский зык. Уже с первых предложений видно, что автор не овладел русским языком, либо с головой ушёл в английский. Так ужасно переводить нельзя.
Про стилистику вы, возможно, правы, но уж падежи-то везде согласованы. Нет?
Для разрешения недорозумений с клиентом хорошо помогает.
Согласование прототипа или эскиза, до начала выполнения дизайна или разработки.
Включение заказчика в определенные стадии работы, в какие решать вам.

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

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

Ну почему нельзя потратить ещё пять минут и сделать русский текст, а не кальку с английского, а то её-богу, пора переименовывать раздел в magic goodie.
— Я же говорю поворачивайте налево, в другое лево!
Два вопроса, которые мы задаем клиентам когда они обращаются за помошью:

— Что мешает вам пользоваться нашим продуктом?
— Какой идеальный вариант решения этой трудности вы бы хотели увидеть?

Обычно эти два вопроса проясняют все желания клиента.
Пользуйтесь на здоровье.
Sign up to leave a comment.

Articles