Довольно забавно слышать как старшее поколение называет всех, от геймера до разработчика баз данных – компьютерщиками. В своей же среде мы называем друг друга программистами, разработчиками или на худой конец специалистами по … Специалистов много, ровно как и технологий, которыми наполнен IT-мир на сегодняшний день. Но всех нас объединяет одно – мы IT-шники. И вот как раз с одним из таких IT-шников у меня возник недавно спор: кто я разработчик программных продуктов (software engineer) или программист(programmer)?

Наш диалог был примерно следующим:

П: Лично я привык называть себя “программер”.

IT: Ты что?! Это же полная ересь. Кто тебя русскому языку-то учил?

П: Где ты слов таких нахватался “ересь”… И что тебе не нравится в термине “программист”?

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

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

Программисты работают в основном водиночку, в то время как разработчики объединяются в группы.

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

П: Мдаа. Так и кто же я по-твоему получаюсь?

IT: Ты типичный IT-шник – не знаешь, чем два слова в родном языке отличаются. А если говорить о том, разработчик ты или программист, то скорее первое. Ты же в команде работаешь?

П: Ага.

IT: Ну вот. Знач, разработчик.

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

Programmer vs. Developer vs. Software Engineer (Joel on Software)

Wiki: Programmer

"Developers" AND "Programmers"

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

О том, что спать на рабочем месте нехорошо, знают все, особенно ваше начальство. Сегодня натолкнулся на интересную статью, рассказывающую об исследованиях доктора Olaf Lahl в этой области. Оказывается, кратковременный сон может значительно улучшить память и умственную деятельность человека.  Ученые провели такой эксперимент. Студентов-добровольцев попросили запомнить список из 30 слов. До проведения данного испытания им был дан часовой перерыв, во время которого некоторым добровольцам предлагалось вздремнуть в течение шести минут, а другим, наоборот, - бодрствовать. Как выяснилось в результате эксперимента, люди, которые воспользовались возможностью вздремнуть, продемонстрировали отличные способности к запоминанию слов - по сравнению с теми людьми, которые не спали.

Что ж, о подобных исследованиях я слышал и раньше, но как уснуть на рабочем месте, когда вокруг стоит рабочий гул? Оказывается уже и эта проблема решена наукой – небольшая утилита Pzizz поможет вам погрузиться в кратковременный сон от 10 до 90 минут. Pzizz начинает и заканчивает сеанс некоторым набором специальных фраз, а во время вашего сна проигрывает некоторую комбинацию мелодий(шум морского прибоя, пение птиц и тп.), влияя таким образом на ход вашего сна. Работа этой утилиты основана на нейро-лингвистическом программировании (NLP) и по словам создателей абсолютно безвредна для вашего здоровья.

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

• возмещение ущерба от инцидентов на работе вследствие ошибок сотрудников
• затраты на непредвиденные отгулы, отпуска, больничные и тп.
• потеря клиентов, вследствие невежливого или неаккуратного обращения сотрудников

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

Так что будем ждать пока прогресс дойдет и до нас или начнем работать дома… 

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

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

Безусловно существует и ряд недостатков:

• зависимость от наличия постоянного соединения (исчезает связь — информация становится недоступной или неудобной в использовании)
• зависимость сайтов от решений сторонних компаний, зависимость качества работы сервиса от качества работы многих других компаний
• слабая приспособленность нынешней инфраструктуры к выполнению сложных вычислительных задач в браузере
• уязвимость конфиденциальных данных, хранимых на сторонних серверах, для злоумышленников (известны случаи хищения личных данных пользователей, массовых взломов учётных записей блогов)

Но тем не менее использование этих сервисов повышает мою производительность, а недостатки медленно, но уверенно сводятся на нет.

Gmail – почтовый сервис от Google. Прост, удобен и надежен.

Google Docs – онлайн-редактор и хранилище моих документов. Помимо присущей гуглу юзабилити, этот сервис радует меня хорошим дисковым пространством и возможностью расшаривать документы моим друзьям, коллегам.

Google Reader – RSS-читалка, привлекающая меня своей простотой и удобством в использовании. (официальный блог разработчиков)

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

Linkedin.com – социальная сеть, постоянно расширяющая круг моих знакомств.

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

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

FolderShare – кросс-платформенный сервис предлагает нечто большее, чем те программы по синхронизации, которые есть у обычных файловых хранилищ. Этот сервис позволяет мне открыть папку у себя на компьютере, а затем быстро синхронизировать ее содержимое с компьютером друга, коллеги, клиента.

Payscale.com – время от времени, оцениваю свое текущее финансовое положение на рынке труда. Хотя полностью полагаться на подобные сервисы в финансовых вопросах и не стоит, тем не менее советую всегда держать руку на пульсе.

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

Ребята из JetBrains выпустили новый решарпер и теперь он доступен для "покупки" и скачивания с их официального сайта.

Пожалуй самая интересная фича нового решарпера - поддержка C# 3.0 и LINQ. Но первая вещь которую я заметил, это "Reformat" переименовали в "Cleanup Code", и поначалу, это сбивало с толку. Зато сейчас эта фича поддерживает профайлы, т.е. различные профайлы могут делать различные "очистки кода": переход к авто-свойствам, использование анонимных типов, формирование readonly полей, если это возможно и многое другое.

Но единственное, что у меня пока не получилось - это редактирование стандартных профайлов.

Следующее, на что я обратил внимание это инициализация объектов, к примеру если я напишу

То решарпер мне предложит поступить следующим образом:

Аналогичным образом решарпер предлагает использовать implicit type variable:

Решарпер советует использовать var везде, где это возможно. Такое решение далеко не всегда оправдано, поэтому я отключил этот функционал.

Зачатки JetBrains.Annotation были еще в решарпере версии 2.5. Если помните был такой "Null Reference Analysis", который оповещал разработчика о возможных NullReferenceException в коде. Чтобы избежать такого анализа разработчики добавляли к свойствам, атрибуты NotNull или CanBeNull, которые решарпер позже использовал для инициализации состояния переменных. В новой же версии количество таких атрибутов значительно увеличилось. Скажем, если вы хотите явно указать, что ваш строковый параметр будет обрабатываться с помощью string.Format, то можете написать следующее

После чего вызвав эту функцию

Довольно удобным стал CamelHumps Completion, позоволяющий писать лишь заглавные буквы ключевых слов, названий классов, переменных:

Как я уже упоминал, теперь решарпер полностью поддерживает C# 3.0 и LINQ, что не может не радовать.

Recent Edits позволяет быстро получить доступ к недавно редактируемым участкам кода (CTRL + "-" уже просто достал!):

И в заключение, хочу добавить, что создатели решарпера клянутся, что он стал быстрее, особенно в обработке ASP.NET кода.

Полезные ссылки:

Официальный сайт решарпера

Новые фичи четвертого решарпера 

Скачать Resharper 4.0 

Купить Resharper 4.0 

Блог Ильи Рыженкова, продукт-менеджера компании JetBrains 

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

Dictionary<string, string> dict;
if (dict.ContainsKey("key"))
	value = dict["key"];
else
	value = "defaultValue";

Поэтому мне пришлось реализовать такую вот нехитрую обертку:

public static class MyExtensions
{
	public static TValue GetValue<TKey, TValue>(
	this IDictionary<TKey, TValue> source, TKey key, TValue defaultValue)
	{
		if (source.ContainsKey(key))
			return source[key];
		else
		return defaultValue;
	}
}

И теперь получить значение стало намного проще:

value = dict.GetValue("key", "defaultValue");

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

10 лет назад	5 лет назад	сегодня

10 лет назад	5 лет назад	сегодня

10 лет назад	5 лет назад	сегодня

10 лет назад	5 лет назад	сегодня

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

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

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

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

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

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

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

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

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

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

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

И что с того?

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