Честно говоря играю я редко, а точнее никогда (в последние полгода). Ибо некогда, ибо неинтересно. Но эту игру я не смог пропустить мимо.

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

Обновление: совсем заработался, вот ссылка на игру.

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

Если ты сделаешь что-то быстро, но плохо, никто не вспомнит, что ты сделал это быстро. Но все скажут, что ты сделал это плохо. Если ты сделаешь что-либо медленно, но хорошо, никто потом не вспомнит, что ты делал это медленно. Но все потом скажут, что ты сделал это хорошо.

Какой нужно сделать вывод? Что? Писать хороший код? С пляжа! Быстро писать надо, а потому криво. Почему? Потому что бизнес не ждет. Это стремительно развивающаяся среда, не терпящая задержек. Именно поэтому большинство коммерчески успешных проектов, убоги с технической точки зрения. Заказчика никогда не будут интересовать архитектура, стиль написания кода или гибкость вашего решения (речь идет о B2C нише). Заказчика всегда интересуют сроки сдачи проекта, реже внешний вид, еще реже производительность или масштабируемость проекта.

Далее автор рассматривает четыре типа программистов:

• первые, что делают все быстро и хорошо
• вторые, что делают все быстро и плохо
• третьи, что делают все медленно и хорошо
• и четвертые, которые делают все медленно и плохо.

Последних отбрасываем за их бесполезностью для человечества. О первых автор метко отмечает:

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

Поэтому, если вы думаете, что наняли лучшего программиста (за N или даже К тысяц долларов в месяц). То поспешу вас разочаровать - лучший программист давно нанял вас.

Остаются два типа, наиболее распространенных типа(по мнению автора) программистов: те, что делают работу быстро и плохо и те, что делают все медленно, но хорошо. О каждом из них довольно толково написано, советую почитать. Из своего опыта могу сказать, что в каждом проекте есть такой период, когда нужно наложить написать кучу вонючего кода. Для этой задачи лучше всего подойдут быстро-плохо программисты. Но в то же время, обязательно наступит момент, когда заказчик спрашивает своего быстро-плохо программиста: "сделай мне паровую микроволновку инженера Гарина на бобовых косточках". На что программист с полной уверенностью заявляет - это невозможно (кстати, отсюда родился миф о "лени" программистов, мол они все могут, вот только ленятся). К сожалению, данного сорта программист не может построить такую систему. Для таких задач как раз и нужен программист медленно-быстро. Поэтому "смешанные" команды наиболее эффективны в нашей объективно-жестокой экономической действительности. Главное - уметь правильно распределять задачи.

Недавно прочел книгу “Психология влияния” Роберта Чалдини, в которой он рассказывает про достаточно интересный психологический аспект деятельности человека. Этот феномен называется "феномен Армейского приказа" и суть его заключается в том, что даже если офицер отдает заведомо ошибочные команды - в большинстве случаев никто из солдат не воспротивится ему, а отправится их выполнять. Даже если они приведут солдат к верной гибели. Со стратегической точки зрения этот феномен невероятно полезен в боевой ситуации. Допустим противник обнаружил небольшое подразделение солдат на открытой местности и начал вести огонь. В тоже время солдаты отделены от противника, минной полосой. Назад бежать - на открытой местности всех перестреляют, вперед бежать - подорвуться на минах. В такой ситуации легко растеряться и погибнуть. Но если офицер даст приказ бежать вперед и вести огонь, то часть солдат(первые ряды) подорвуться на минах, часть убьет противник, но часть выживет. Ошибочное ли было это решение? Везде ли этот феномен будет полезен?

Интересно, что в бизнесе ситуация очень похожа. Руководители вполне могут совершать ужасные “ошибки”, которые приводят к краху бизнеса. Даже если эти CEO такие звезды, как Стив Джобс или Говард Шульц.

Большинство газет (включая New York Times) еще пару лет назад восторгались стратегией, которую выбрал основатель сети кофеен Starbucks – кофейня на каждом углу. Starbucks появлялся везде, где только можно. USA Today назвала его «кофейным Биллом Гейтсом». Кофеен стало так много, что люди, если и не начали теряться, то, по крайней мере, перестали посещать многие из заведений Говарда Шульца. Сегодня легендарная компания закрывает сотни кофеен, а людей увольняет тысячами. Говард Шульц попал в рейтинг самых худших CEO года по версии журнала Fortune.

А ведь еще недавно его боготворили за те же самые поступки… просто последствия были иными. Но во время успешного периода деятельности компании никто и не подумал возразить основателю Starbucks. Сейчас его поливают грязью бизнес-издания Америки. И это не только проблема Starbucks. Любые руководители ошибаются. Они тоже люди, и имеют на это право. Другой вопрос в том, что сотрудники не должны быть заложниками феномена Армейского приказа. Они всегда должны анализировать ситуацию, и если кто-то понимает, что шеф не прав, то нужно постараться объяснить ему это. Естественно, приведя убедительные доказательства. А слушают ли вообще сотрудников?

Тут, конечно, многое зависит от самой компании. А может ли в ней простой сотрудник сказать старшему менеджеру или даже президенту, что тот совершил ошибку? Послушают ли его вообще? На этот вопрос нет однозначного ответа. Это уже скорее проблема корпоративной культуры. В любом случае, очевидно, что руководство в большинстве нормальных компаний старается выслушивать своих сотрудников. Обычно при помощи электронной почты (если речь идет не о малом бизнесе). Помимо клинических случаев, большинство компаний для связи руководителя и сотрудника используют простую корпоративную почту, или внутреннюю сеть. Правда, достаточно часто письма сначала проходят проверку у секретарей главы компании, которые направляют к нему только самые важные. Например, именно так дела обстоят в компании Microsoft, когда письма идут Биллу Гейтсу. С президентом компании – Стивом Баллмером, ситуация иная. Он сам отвечает на все письма без помощи секретарей. При этом email Баллмера открыт для всех, благодаря чему он получает электронную почту и от клиентов компании, и от простых людей, которые неожиданно решили отправить письмо Стиву.

Возращаясь к примеру Говарда Шульца и феномену Армейского приказа, можно сказать, что Шульц принял ошибочное решение. Хотя в 2006 году, журнал Forbes назвал Говарда Шульца 354-ым наиболее богатым человеком Соединенных Штатов, а его состояние оценивается в 1.1 миллиард долларов. Возможно, это и есть та, часть отряда которая выжила? Мораль такова – не важно кто вы – солдат или разработчик программного обеспечения – всегда старайтесь спасти ваш отряд, или по крайней мере оказаться в той части, которая выживет ;)

Запомните клиент всегда хочет чувствовать себя любимым и быть в центре внимания. Даже если это внимание одного маленького трудяги-программиста. На эту чудо-мысль меня натолкнул недавний случай.

Немного предыстории. Проект, над которым я и моя команда сейчас работаем, имеет богатый функционал и предназначен для проведения маркетинговых исследований. Заказчик, по всей видимости, успешный хозяин своего бизнеса. И постоянно сыпет новыми идеями. Порой случается так, что его новые идеи перекрывают или отменяют прошлые “новые” идеи. И как все нормальные заказчики, он переживает за свой продукт и за свои деньги. Ежедневное общение с ним, стало для нас нормой. Неделю назад мы, как обычно, получили новый список ToDo и приступили к исполнению. Вопросов не было – функционал был предсказуем и даже ожидаем. И тут клиент сменил свою позицию на более пассивную, перестал ежедневно задрачивать интересоваться ходом разработки. Мы были увлечены разработкой и тоже не беспокоили заказчика. И каково же было мое удивление, когда в следующий понедельник я обнаружил у себя в ящике гневное письмо клиента: “Почему вы не выпустили следующую версию продукта? Где новый функционал? Вы что не работали всю эту неделю?”. После недолгих объяснений все стало на свои места, но после этого случая я сделал для себя несколько выводов.

Помнить о клиенте. Даже если у вас нет новостей, то хорошим тоном будет написать письмо, хотя бы с одним словом “Привет(Hello)!”. Тем самым вы покажете заказчику, что вы думаете о нем и “держите” его проект у себя в голове.

Держать клиента в курсе событий. Это хорошая идея – отправлять заказчикам регулярные письма с информацией о прогрессе проекта. Не стоит этого делать часто. Если ваш проект долгоиграющий и изменения в нем происходят медленно, то достаточно будет одного письма в неделю. Хотя на некоторых проектах необходимо оповещать клиента об изменениях по нескольку раз в день. Интересно и то, что если “приучить” клиента к письмам каждую пятницу, то через месяц самое простое пятничное письмо, с текстом “Привет, как дела?” будет означать, что проект двигается по плану и заказчик будет спокоен.

Позвольте клиенту почувствовать вашу проактивность в проекте, даже если вас об этом никто и не просил.

В завершение хочу предложить вам пройти небольшой тест.

У вас появился новый клиент и вот-вот начнется работа по этому проекту. Проект будет длиться два месяца. Ваши действия:

1. Уйду в отпуск – ведь следующие два месяца будут сплошной каторгой.
2. Устрою собрание всех участников проекта для согласования сроков, задач и целей.
3. Заставлю клиента заплатить сразу и начну переговоры о покупке конкурента.

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

1. Скажу: “Проблема? Какая проблема? Эти туфли подходят цвету моих глаз, неправда ли?”
2. Позвоню клиенту и назначу встречу, чтобы обсудить текущие задачи по проекту.
3. Позвоню заказчику: “Какого хуя? Где обещанные премиальные?”

День рождения клиента. Ваши действия:

1. Серьезно? У клиентов бывают дни рождения?
2. Пошлю цветы или бутылочку шампанского.
3. Пошлю счет за этот месяц с подписью: “С днем рожденья, сука!”

На встречах с клиентом, вы:

1. Опаздываю на 30 минут. Часто забываю свой ноутбук с последними изменениями дома и приходиться возвращаться.
2. Приезжаю вовремя, предлагаю клиенту кофе и сладкое.
3. Не появляюсь: “Время – деньги, Джонни.”

Термин “шлифовать” для вас:

1. Процедура, которая должна быть выполнена, до того как шкаф покроют лаком.
2. Проверить все ли завершено, согласно проектному договору. Собрать все документы. Проверить еще раз.
3. Поджечь, утопить или съесть все, компроментирующие вас документы.

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

Subversion всегда был удобен такими фичами как, атомарные commits, версионированные директорий, хорошая поддержка бинарных файлов, быстрое создание бранчей и тагов, поддержка нескольких сетевых протоколов, в том числе и HTTP. Но, чего действительно раньше не хватало в subversion, так это возможности найти какой код был смержен, откуда он мержился и когда это произошло. Отсутствие такой возможности приводило раньше к трудностям при мерже:

К примеру, пользователь не сможет смержить изменения с 11 по 17 ревизию в бранч, если он уже мержил 11 и 13 ревизии в бранч ранее. В новом subversion мержи логируются и нет больше необходимости записывать на листик, какой код, когда и откуда мержился.

Разработчики subversion как будто услышали мои мольбы и добавли change lists –функционал, позволяющий ассоциировать произвольные файлы с неким человекочитаемым именем. К примеру вы работаете над несколькими багами одновременно, и по окончании одного из них хотите залить его в репозиторий. А файлы, относящиеся к другому фиксу – оставить в локальном репозитории. Раньше приходилось прибегать к помощи листика, чтобы разделить эти два набора файлов и залить только нужные файлы. Теперь проассоциировав первый набор файлов с неким именем, вы можете по окончанию работ просто указать имя этой группы файлов и они немедленно попадут в основной репозиторий.

Еще одна полезность, появившаяся в 1.5 subversion – это sparse checkouts, позволяющий выполнять основные операции только над указанными уровнями дерева каталогов. Это удобно, если вы не хотите “слить” только текущий каталог со всеми файлами в нем, но не хотите “сливать” все его поддиректории. 

Также было добавлено интерактивное разрешение конфликтов – теперь svn сам предлагает варианты решения конфликта. Лично для меня эта фича никакой погоды не делает, так как я давно пользуюсь Araxis Merge, чего и вам советую.

Не знаю почему, но большинство GIT’овцев кричат: SVN sucks, попробуйте GIT – у нас проект в жите 2.5 гига и ничего не тормозит. У меня, я вам скажу, есть проект около 4 гигабайтов в архиве. То есть сжатый RAR’ом. И я никаких тормозов не наблюдал еще с версии 1.4.6. А в версии 1.5 ускорена работа из-за простого трюка – они сделали более многовложенную файловую систему, т.е. в одной директории такого дикого количества файлов уже не будет. И это важно, особенно, если ваш сервер хранит репозиторий на Network Attach Storage с не самой продвинутой файловой системой, которая тормозит при 10 000 файлов. Из-за того что в subversion файлы readonly, это позволяет улучшить стратегию кэширования на стороне NAS’ов и других умных файловых систем. Теперь неизменяемые файлы сгруппированны в каталоги, и вашей файловой системе можно сказать: вот эти каталоги неизменяемы (после появления файлов в ней) и ты пожалуйста это учти.

Разработчики клянуться, что теперь заработает CTRL+C!

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

Как мы видим, управлять репозиторием теперь станет легче, работать он будет быстрее, а разработчики перестанут записывать на листике, что и когда они мережили ;)

Ссылки по теме

Subversion 1.5 Release Notes

Subversion: чеклист по правильным коммитам

Слияние: Руководство по ежедневному использованию

Merging and branching in Subversion 1.5

Subversion or CVS, Bazaar or Mercurial?

Get that job at Google - очень интересная статья с советами по поводу того, как проходить собеседование в Гугле. И она не зря такая популярная, она действительно очень хорошо и вдумчиво написана. Там рассматривается процесс собеседования в принципе, и даются советы, которые подойдут для прохождения собеседования в любых программерских компаниях.

Компании наподобие Гугла ставят высокий барьер, при отборе кандидатов. Лучше отказать квалифицированному кандидату, чем взять на работу неквалифицированного.

Спорный вопрос, но думаю, Гуглу виднее.

Не стоит переживать, если вас не взяли на работу. Причинами для этого могут быть:

1. у вас был просто неудачный день
2. у вашего интервьювера был просто неудачный день
3. вы просто не поняли друг друга (вас и интервьювера) на собеседовании
4. вам не повезло и вы попали на Interview Anti-Loop

Полностью согласен с автором. Не стоит волноваться и во время собеседования – это может понизить ваши шансы на успех.

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

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

На собеседование необходимо всегда приходить подготовленным.

Даже если вы лучший программист в своей компании, если вы уже долгое время успешно пишите крупный и сложный проект, это вовсе не значит, что вы сможете ответить на все вопросы интервьювера. Ведь удержать в голове знания всех алгоритмов, технологий и подходов с которыми вы сталкивались невозможно. А если на каждый второй вопрос вы будете отвечать: “Да я сталкивался с этим, но это было очень давно и сейчас я не могу ответить на ваш вопрос.”, – то у интервьювера сложится впечатление, что вы самоуверенный, высокомерный и ничего не умеющий джуниор. Поэтому необходимо освежить память перед собеседованием.

Шаг 1 – Изучить теорию алгоритмов и структур данных . Зачем? Потому что это поможет вам распознать проблему, которую вам предлагают решить на собеседовании. Большинство интервьюверов любят, когда их вопрос понимают без дополнительных пояснений. К примеру, если вас попросили разукрасить флаг Штатов, то вашим большим плюсом, будет увидеть в этом вопросе проблему раскрашивания графа. А если вы еще вспомните и решение данной проблемы, то ваши шансы пройти собеседование резко повысятся.

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

Автор рекомендует две книги для подготовки в области теории алгоритмов и структур данных: The Algorithm Design Manual Стивена Скинса и Introduction to Algorithms Томаса Кормена. От себя порекомендую Алгоритмические трюки для программистов Генри Уоренна и Алгоритмы: построение и анализ того же Т. Кормана. В свое время эти книги помогли мне занимать призовые места на национальных соревнованих по программированию.

Шаг 2 – Попросите товарища прособеседовать вас. Друг должен задавать вопросы из различных областей. И вы должны отвечать на них, не важно насколько вы устали или просто ленитесь на них отвечать.

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

Не ведите себя высокомерно на собеседовании. Лучший способ показать свое высокомерие – поставить под сомнение профессионализм собеседника, поэтому никогда не спрашивайте: “Вы действительно считаете, что все эти алгоритмы важны? Вы полагаете их стоит использовать в реальной жизни? Никогда не слышал о подобном подходе…”. Лучше просто признаться, что вы не знаете или не помните ответ на этот вопрос. Также, не бойтесь попросить подсказку или помощь при ответе на вопрос – некоторые интервьюверы любят, когда их талант признают и просят у них помощи.

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

Некоторые интервьюверы не просят написать кусочек кода, но в вопросе подразумевают, что это было бы лучшим ответом. В этом случае, лучше спросить. Также можно поинтересоваться отношением интервьювера к коду – будет ли он переживать по поводу того, что синтаксис не везде будет соблюдаться? Некоторые интервьюверы равнодушны к синтаксису, полагая, что главное это общее понимание решения и алгоритм. Другие же, напротив – придираются к пропущенной точке с запятой или незакрытой скобке. Но не стоит и сразу бросаться в бой, писать код, даже если вы знаете правильный ответ. О вас может сложиться мнение, что вы сразу беретесь за реализацию, игнорируя этап проектирования. Лучше спросить.

В качестве одного из советов для технической подготовки к собеседованию, автор далее дает совет получить техническое образование. Я, как человек обладающий подобным образованием, могу с уверенностью заявить – в нашей стране это вовсе необязательная вещь. Еще ни на одном из собеседований, на которых мне довелось побывать (а их уже наберется с два десятка), меня не спросили о моем высшем образовании. Единственный раз меня спросили пару лет назад – не являюсь ли я студентом и если да, то буду ли брать отпуск на время сессии… Все.

Интересным и несколько необычным мне показалось еще и то, что в Гугле проверяют базовые знания математики. Вообще-то не только в Гугле, но и в Мелкософте такое практикуют, просто я никогда не слышал о подобных вопросах при приеме на работу в украинские ИТ-компании.

Операционные системы. Большинство интервьюверов спрашивают в основном фундаментальные вещи: что такое процесс, потоки, какие ресурсы им необходимы, как работает переключение контекста, как происходит инициализация операционной системы и подключенного оборудования, что такое concurrency issues и т.п. Также вы должны знать, что такое locks, симафоры и мониторы и как они работают. Могут спросить, что такое deadlocks и livelocks и как их избегать.

Лучшая книга, которую я прочитал на эту тему – Concurrent Programming in Java Дуга Ли.

В некоторых компаниях меня спрашивали не только о различных семействах операционных систем(MacOS, Linux, Windows), но и отличия версий в одном семействе (Windows XP и Windows Server 2003).

Языки программирования. Вы должны знать хотя бы один язык программирования хорошо и лучше всего, если это будет С++ или Java. С# тоже подойдет, так как он похож на Java. И вы должны быть готовы написать идеальный кусок кода на этом языке.

Честно говоря, я думал, что к этому списку еще добавиться Perl. Но автор оставил его почему-то без внимания.

Итак, предупрежден – значит, вооружен! Но даже если после такой подготовки вы не прошли собеседование – не расстраивайтесь, ведь всегда можно попробовать еще раз (…через полгода).

Ссылки по теме

Одна история неудачного собеседования в Гугл

Записки русского программера из Гугля

How I Blew My Google Interview

My interview experience with Google

My interview at Google

Google's Interview Questions

Google Top Interview Questions ( around 30 With Solutions)

Google Interview for Freshers

Google interview

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

#1 Правильно ли вы поняли суть проекта?

Заказчики народ ленивый, а потому добиться от них подробной документации или спецификации будущего проекта непросто, особенно если проект небольшой. Зачастую менеджеры проектов получают, так называемую, user story. Потом этот документ усилиями менеджера или кого-то еще эволюционирует в спецификацию – более подробный документ с техническими терминами. И вот тут есть риск совершить первую, а зачастую и роковую ошибку – не поделиться этим документом с заказчиком. Ведь заказчик под словом “usability” имел ввиду не квадратную, а круглую кнопку! В лучшем случае такое недоразумение выльется вам в пару лишних часов работы, а в худшем – превышение бюджета/времени проекта, потеря/отказ от заказчика. Поэтому даже если вы и не планировали составить что-то похожее на спецификацию, то по крайней мере выслать скриншоты аналогов или описание проекта своими словами – было бы хорошим шагом в сторону от этих граблей.

#2 Не слишком ли часто, вы общаетесь с заказчиком?

Согласен, несколько противоречивый момент. В предыдущем пункте я рекомендовал дополнительно общаться с заказчиком, а теперь намекаю на то, что это не всегда полезно. Это действительно так. Наиболее плотное общение полезно в начале проекта, когда каждый участник, в том числе и заказчик пытаются понять и “построить” проект у себя в голове. Но дальнейшее общение по 2–3 часа в день может губительно сказаться на проекте, ведь во время этих дискуссий у заказчика появляются множество новых идей, не предусмотренных ни бюджетом, ни архитектурой проекта. Ежедневные вопросы “А в каком состоянии сейчас проект?”, “А кто над чем работает в данный момент?” и т.д. не только вызывают раздражение, но и отнимают и без того драгоценное время. И даже если заказчик отвлек вас всего на мгновение вопросом “А как пройти в библиотеку?”, то вам понадобиться от 10 минут до часа времени, чтобы вернуться в рабочее русло и восстановить свою производительность. Поэтому, если вам позовляет ситуация, ограничтесь общением по почте, оставьте номер телефона на пожарный случай – и никаких мессенджеров! Тем не менее онлайн общение необходимо на любом проекте – организуйте это в виде заранее спланированных коференц-звонков или собраний с точным регламентом по времени.

#3 Позволяете ли вы заказчику саботировать проект?

Заказчик может саботировать проект множеством способов – вносить в проект новые идеи или функционал; указывать вам как именно необходимо реализовывать ту или иную часть проекта; сокращать сроки сдачи работы и так далее. Был у меня один проект, на котором мы выполняли любую прихоть заказчика, крутили архитектурой проекта так, что через месяц ее было просто не узнать. А сам проект из узконаправленного решения превратился в некую платформу для решения “всех” проблем, в том числе и глобального потепления. Во время этого процесса заказчик был доволен как слон таблеткой, но как только подошло время первой бета-версии – он взгрустнул… Взгрустнул оттого, что бета не вышла, ведь последний месяц мы писали не запланированный функционал, а переделывали проект под новые идеи заказчика. В итоге все остались в проигрыше – мы без заказчика, заказчик – без продукта. Мораль проста – научитесь говорить НЕТ, даже если вы хотите угодить вашему клиенту.

#4 Дело дошло до спора?

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

#5 Что вы делаете, когда клиент недоволен?

Пытаетесь оправдаться? Перенести вину на заказчика? Доказать, что всему виной фаза луны? Все это, безусловно, пути решения проблемы, по которым иногда приходится идти. Но зачастую, наилучшим способом вернуть заказчика в прежнее, довольное состояние – это показать, что вы с ним одна команда и находитесь по одну сторону баррикад и, что вы заинтересованы в решении возникшей проблемы не меньше его самого. Даже если бюджет уже исчерпан, время подходит к концу, то фраза “да, это проблема, но мы поможем вам ее решить” заставит смотреть на вас с благодарностью. А следующая фраза “…но на это нам нужны будут новые $” будет звучать не так удручающе, как фраза “это не наша, а ваша проблема. Денег больше нет, помочь ничем не можем.”

И что с того?

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