Как строить взаимоотношения с заказчиками/подрядчиками?

Ноябрь 23rd, 2009

Тут в прошлой статье мне задали вопрос: «как строите взаимоотношения с заказчиками/подрядчиками ? Т.е. устные договоренности, бумажные договора, риски, действия при срабатывании рисков и т.д.»

Скажу честно, в технической стороне менеджмента я чувствую себя гораздо более компетентным, чем в работе с заказчиками. Впрочем, я думаю это свойственно большинству технарей. Тем не менее, последние X лет (где-то от 5 до 7, смотря как считать) кое чему меня научили.

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

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

В целом, все, что важно для вас и заказчика и может быть определено заранее — должно быть в контракте. Чаще всего это
— деньги
— сроки
— объемы работы

Ну и стандартный кусок контрактов

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

В целом, если вы поищите большинство consulting agreement’ов будут иметь все эти пункты.

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

Кстати, еще одна важная вещь. Контракт не высечен в камне. Если происходят какие-то изменения, то можно подписать дополнения к контракту. Это правильнее, чем держать их в голове.

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

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

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

Насчет подрядчиков. В целом все тоже самое. Единственное, проактивность стоит воспринимать по другому. Со стороны заказчика под проактивностью я понимаю — постановку задач, их приоритезацию и объяснений тех критериев, которые для него важны. Подрядчики — люди и не умеют читать мысли. Очень многие заказчики наступают на грабли, что они ожидают чего-то от исполнителя, что никогда не было оговорено.

Ну и пару мелких замечаний.

— Если заказчик или подрядчик не хочет подписывать (разумный) контракт, то стоит ооочень серьезно задуматься о дальнейшем сотрудничестве. Аналогично, если из контракта пытаются выбросить стандартные пункты. Большинство контрактов обтачивались достаточно долгий срок, чтобы быть достаточно универсальными.

— Чтобы не происходило в переговорах с заказчиками и подрядчиками, пытайтесь оставаться спокойными. Горячая голова — самый худший советник.

Программисты съели мой мозг.

Ноябрь 20th, 2009

Вспомнились несколько разных случаев.

— Как-то объяснял двум Senior Software Developer’ам, которые проработали в компаниях разрабатывающих security по крайней мере по нескольку лет, что такое битовые операции.

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

— Как-то было, что за 4 часа переписал код, который другой разработчик писал две недели. Причем за это время уменьшил объем код в 16 раз, не потеряв функциональности и не ухудшив читабельности.

— Помогал другому senior software developer’у пофиксить баг — поставить в нужном месте скобку. Причем, компилятор указывал, где должна быть вставлена скобка и что ее там не хватает.

— Хоть не о разработчиках, но тоже хорошо. Работал с заказчиком (который технарь и достаточно долго ведет IT бизнес), который считал, что в проекте можно исправить ВСЕ ошибки.

— И тоже не о программистах. На конференции видел sales, который на Palm не знал как перейти в Launcher (аналог Program Files для Windows). При этом он продавал сложную систему (включая Palm клиента) и должен был отвечать на вопросы.

С удовольствием послушал бы ваши житейские истории, о том как окружение кушает ваш мозг.

Программисты украли мой проект.

Ноябрь 11th, 2009

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

Ну и соответственно, предотвращение такой ситуации становится Большой головной болью владельца .
И если вдуматься, ситуация абсолютно аналогичная тому, как выкидывают посредника в случае если он перестает приносить выгоду.

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

В целом есть три направления, в которых надо двигаться.

а) Контракт с заказчиком

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

б) Нормальные отношения с своими подчиненными.

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

в) Компания (как посредник) должна быть полезна для заказчика.

Вот этот пункт достаточно сложны. Чаще всего все IT компании, которые делают проекты фактически предоставляют услуги, которые составляют 100% их пользы. Чаще всего нету особо дорогого оборудования, которые отделившиеся программисты не смогли бы себе позволить.

Одна из хороших идей, лицензирование им (даже за бесплатно) какие-то из своих библиотек. Эта та самая Intellectual Property, которая будет являться дополнительной пользой.

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

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

Продуктомысль.

Ноябрь 3rd, 2009

Давным-давно на заре своего блога я написал статью о том, как выбрать какой продукт делать. Хотя в целом статья правильная, добрая и умная, но сейчас я вижу, как многое было мной сделано допущений и упрощений, учитывая отсутствие реального опыта ведения продукта.

Сейчас, после где-то 9 месяцев (с перерывами) с начала разработки продукта, уже таки набил достаточно шишек, чтобы более взвешено взглянуть на выпуск продукта.

Так, что комментирую свою же старую статью. Сначала, пытался прокомментировать по пунктам, потом осознал, что у меня к всем пунктам один и тот же комментарий, который я повторяю снова и снова. И таки решил не мучать вас девятикратным повторение.

Просто напишу пункты из той статьи, к которым комментарий относится

>6) Идея должна быть размеров, которые можно потянуть
>2) У идеи должен быть рынок.
>1) Идея должна решать реальную проблему.
>5) Идею нужно иметь возможность сделать лучше чем конкуренты.

Охохонюшки…. Я с своим продуктом конкретно влип по всем статьям.

Деньги и время, деньги и время, деньги и время… Блин, эту мантру нужно повторять каждый день. В тот момент, когда она наконец дойдет до мозга, наступит счастье.

Даже супер идея и супер реализация не доведенная до конца вероятнее всего будут стоить ровно круглый нолик.

С самого начала нужно планировать бюджет — денег и времени. И все с двукратным запасом, так как и то и другое выбьется из под контроля.
Никаких мечтаний о миллионе крутых фич и кучи мелких красивостей — четкий и холодный расчет… Даже, для продукта, который по вашему мнению займет сделать всего один месяц. Еще раз — деньги и время, деньги и время.

Так вот «деньги и время» должны стать коэффициентом, на который вы должны домножить абсолютно все. Есть идея, которая должна покорить рынок в 5 миллиардов баксов? А теперь домножьте на свои накопления в $123 и по полчаса в день по вечерам, которые вы собираетесь вложить. Умножили? Так вот, результат равен нулю.

Этот самый коэффициент точно также относится относится и к тому, что идея должна решать реальную проблему. Может ваша идея и решает
проблему, но вот реализация = идея*(деньги+время). И если второй множитель маленький, прощай решение проблемы.

Аналогично и с конкурентоспособностью.

Так, что повторяю еще раз — деньги и время.