И все таки ключевое и единственное в конечном счете отличие хорошего от плохого работника — это внутренняя мотивация. Если она есть, то и опыт и умения наберутся, если ее нет — то пиши пропало.
Не деньги, не пинки, не просьбы не работают так эффективно, как абсолютно бессмысленное и необоснованное желание развиваться и делать свое дело хорошо.
Тут в прошлой статье мне задали вопрос: «как строите взаимоотношения с заказчиками/подрядчиками ? Т.е. устные договоренности, бумажные договора, риски, действия при срабатывании рисков и т.д.»
Скажу честно, в технической стороне менеджмента я чувствую себя гораздо более компетентным, чем в работе с заказчиками. Впрочем, я думаю это свойственно большинству технарей. Тем не менее, последние X лет (где-то от 5 до 7, смотря как считать) кое чему меня научили.
Самое важное — это документировать все ваши отношения. Поверх благих намерений, которыми вымощенная дорога в ад, лежит мощный трехметровый слой из устных договоренностей.
Не обязательно даже заказчик зараза и хочет вас кинуть. Просто, человеческая память так устроена, что она не может точно воспроизвести сказанную фразу даже несколькодневной давности. Вот и получается, что вы в начале проекта сказали — это займет четыре с половиной — пять с половиной месяцев. Заказчику запомнилась цифра четыре месяца, вам запомнилось — пять с половиной. Проект продлился пять месяцев и неделю. Вам кажется, что вы сдали раньше на неделю, заказчику кажется, что вы просрочили на месяц и неделю.
В целом, все, что важно для вас и заказчика и может быть определено заранее — должно быть в контракте. Чаще всего это
— деньги
— сроки
— объемы работы
Ну и стандартный кусок контрактов
— собственность (кто владеет чем по окончанию проекта)
— что вы гарантируете (а что нет)
— о невмешатесльстве в бизнесы друг друга (а-ля наем чужих сотрудников)
— окончание контракта
— эксклюзивность
В целом, если вы поищите большинство consulting agreement’ов будут иметь все эти пункты.
Если что-то заранее не может быть определено, лучше всего запишите в контракт либо диапазон (например 4-6 месяцев), либо методику по которой будет определяться значение («длительность проекта буду указана в дополнение к контракту после исследования предметной области»).
Кстати, еще одна важная вещь. Контракт не высечен в камне. Если происходят какие-то изменения, то можно подписать дополнения к контракту. Это правильнее, чем держать их в голове.
Вторая вещь, которой я лично пользуюсь — это честность и открытость. В контракте не возможно предусмотреть 100% ситуаций. Плюс, никакой контракт не удержит заказчика от ухода к другому исполнителю. Поэтому, как по мне, лучше в открытую обсуждать с заказчиком информация, которая для него важна.
Третье, я считаю, что нужно быть проактивным. Например заказчик не оговорил, насколько часто нужна отчетность — предложите ему ваш стандартный вариант и попросите его дать вам знать, если он хотел бы от вас другую частоту отчетности. Ведь понятно, что если заказчик вам не сказал про отчетность, то он все не будет счастлив тому, что вы исчезнете на два месяца погрузившись в разработку.
По поводу рисков. Как по мне, тема отдельная и большая. Единственное, что по этому поводу могу сказать, что я обычно считаю, что один раз — случайность, два раза — совпадение, три — закономерность. То есть, если заказчик выкидывает какой-то фортель первый раз и при этом он был на хорошем счету — то вполне это дело можно пропустить, но если проблема серьезная и повторяется три раза, то лучше всего сворачивать сотрудничество. Как показывает практика — отсутствие сотрудничества лучше, чем плохое сотрудничество.
Насчет подрядчиков. В целом все тоже самое. Единственное, проактивность стоит воспринимать по другому. Со стороны заказчика под проактивностью я понимаю — постановку задач, их приоритезацию и объяснений тех критериев, которые для него важны. Подрядчики — люди и не умеют читать мысли. Очень многие заказчики наступают на грабли, что они ожидают чего-то от исполнителя, что никогда не было оговорено.
Ну и пару мелких замечаний.
— Если заказчик или подрядчик не хочет подписывать (разумный) контракт, то стоит ооочень серьезно задуматься о дальнейшем сотрудничестве. Аналогично, если из контракта пытаются выбросить стандартные пункты. Большинство контрактов обтачивались достаточно долгий срок, чтобы быть достаточно универсальными.
— Чтобы не происходило в переговорах с заказчиками и подрядчиками, пытайтесь оставаться спокойными. Горячая голова — самый худший советник.
Не знаю насколько во многих фирмах такое происходило, но в целом дело достаточно распространенное (в exUSSR), когда программист или менеджер проектов уходит с заказчиком (я говорю о офшорных фирмах, которые делают проект на заказ).
Ну и соответственно, предотвращение такой ситуации становится Большой головной болью владельца .
И если вдуматься, ситуация абсолютно аналогичная тому, как выкидывают посредника в случае если он перестает приносить выгоду.
Да, кстати, чтобы расставить все на свои места. Я не верю, что в exUSSR можно нормально эту проблему решить в легальном поле, так как попадание в суд, даже в виде обвиняющей стороны длинный и болезненный процесс. Ну и решение ее в нелегальном поле — а-ля «послать двух парней с паяльником — пообщаться» не наш метод тоже.
В целом есть три направления, в которых надо двигаться.
а) Контракт с заказчиком
Да, программисты не бояться того, что их засудят. Но заказчики, находятся в правовых странах, да и терять им есть гораздо больше.
Поэтому контракт в котором сказано о том, что никаких бизнес отношений с сотрудниками вашей фирмы в течении X лет просто необходим.
б) Нормальные отношения с своими подчиненными.
Нельзя сказать, что это полностью решает проблему, но явно уменьшает ее вероятность. В большинстве случаев, уводят проект именно те, кому наступили на любимую мозоль, а потом станцевали на ней джигу.
в) Компания (как посредник) должна быть полезна для заказчика.
Вот этот пункт достаточно сложны. Чаще всего все IT компании, которые делают проекты фактически предоставляют услуги, которые составляют 100% их пользы. Чаще всего нету особо дорогого оборудования, которые отделившиеся программисты не смогли бы себе позволить.
Одна из хороших идей, лицензирование им (даже за бесплатно) какие-то из своих библиотек. Эта та самая Intellectual Property, которая будет являться дополнительной пользой.
г) Желательно не держать все яйца в одной карзине. Например, менеджер проекта с вашей стороны, чтобы работал с менеджером с той стороны, а с ваш бухгалтер (или вы) работали с владельцем/финансовым директором с той стороны.
Проекты чаще всего уводятся именно тогда, когда с той стороны владелец уже отлично знает менеджера или программиста и этот менеджер/программист ему предлагает «урезать расходы» путем работы напрямую.
В прошлой статье Andrey Yasinetskiy сказал, что мой манифест работодателя противоречит Agile. Я так взял, взвесил agile практики, которые знаю, почесал в голове, отписал, что они не противоречат. А потом я полез и прочел Agile software development статью в wiki. и обнаружил, что большинство практик на самом деле противоречат первому же пукнту Agile манифеста.
Самый первый пункт манифеста — «Individuals and interactions over processes and tools«. Блин, да половина agile дисциплин основана именно на следовании процессов. Test driver development, continuous integration, code refactoring, iterative development — это же все процессы. Причем, если взять какие-нибудь уже готовые методики (а-ля того же SCRUM) то эти процессы там уже четко прописаны, описаны, роли, действия, артифакты и т.п. Да, естественно в каждой из них есть «individuals and interactions», но как только individual решать забить на процессы, которые им не нравятся — а-ля перестанут код класть в source control, остановят систему генерящую билды и перестанут делать итеративную разработку, вот тут как раз и придет пипец их попыткам работать Agile.
Кстати, аналогично насчет послднего пункта Agile манифеста «Responding to change over following a plan«. Это не значит, что надо нафиг забить на план. Это значит, что план должен изменяться в зависимости от внешних событий.
В целом, можете в меня хоть помидорами кидать, но Agile Manifesto в чистом виде — это радужные мечты богемы IT мира. Для всего же остального мира, Agile практика (которая таки требует процессов и изменчивого плана) кроет как бык овцу Agile теорию.
