Array Array - Getting Real

Не разделяйте лишний раз

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

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

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

Людям нужно время, чтобы постоянно добиваться своего

Сотрудники 37signals находятся в четырех городах и в восьми часовых поясах. От Прово, штат Юта до Копенгагена, Дания. Есть только 4-5 часов в течение дня, когда мы работаем вместе. Когда наша команда спит, Давид, который находится в Дании, работает. Мы работаем, Давид спит. Это дает нам только половину дня для совместной работы.

Можно предположить, что и время работы, и эффективность от работы сокращается вдвое. Но это нет так.

Известно, что многие люди предпочитают работать рано утром или поздно вечером — это время когда их не беспокоят, это время самое продуктивное для них. Это время становится таким, потому что никто не прерывает работу, и никто не отвлекает.

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

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

Никаких встреч

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

Нет страшнее яда для производительности, чем встреча. У этого несколько причин:

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

* Встречи — это всего лишь слова и абстрактные понятия.

* Встречи несут безнадежно мало полезной информации в минуту.

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

* У встреч есть повестки дня, такие неопределенные, что часто никто действительно не уверен в том, что надо обсуждать.

* Встречи требуют большой подготовки, чего почти никто не делает.

Если все-таки вы не можете избежать встречи (что должно быть очень редким событием), воспользуйтесь простыми правилами:

* Встреча должна быть не более 30 минут. Установите таймер, после 30 минут прерывайте встречу.

* Пригласите как можно меньше участников.

* Никогда не участвуйте во встрече без ясной повестки дня.

Выпустите что-нибудь сегодня

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

Долгие, затянутые циклы разработки — убийцы мотивации. Это слишком долгое время между празднованием побед. Быстрые победы — факторы мотивации. Если вы допускаете длинные циклы разработки — вы убиваете мотивацию. И это может убить ваш продукт.

Среди многих месяцев разработки посвятите один день в неделю для маленькой победы. Спросите себя: «Что можно сделать и выпустить за 4 часа?». Затем сделайте это.

Это может быть:

* Новая простая особенность

* Маленькая доработка существующей особенности

* Написание некоторого текста помощи, чтобы сократить бремя поддержки

* Удаление нескольких полей форм, которые вам действительно не нужны

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

Добавляйте медленнее, чтобы двигаться быстрее

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

Так что не нанимайте. Серьезно, не нанимайте никого. Взгляните на это с другой стороны — действительно ли работа, которая вас отягощает, так необходима? Что случиться, если вы просто её не сделаете? Можете ли вы решить проблему с данной частью системы другим способом?

Каждый раз когда Jack Welch (former CEO of GE) увольнял кого-либо, он не нанимал человека взамен сразу. Он хотел посмотреть как долго GE может обходиться без данной персоны и его роли. Конечно, мы не призываем увольнять людей, чтобы проверить эту теорию, но мы думаем, что Jack настаивал на чём-то вроде: «Вам не нужно столько людей, сколько вам кажется необходимым».

Если нет никакого другого варианта — рассмотрите возможность найма нового человека. Но вы должны точно знать кто вам нужен, как вы введёте его в работу и как много головной боли обретёте.

Привлечение людей к просроченному проекту задержит его ещё больше.

Хороший одиночный программист, работающий над отдельной задачей, не имеет над собой проблем координации работы и общения. Пять программистов, работающих над той же задачей, обязаны общаться и координировать свои действия между собой. Это занимает много времени... Основная проблема с использованием группы посредственных программистов вместо парочки хороших состоит в том, что не имеет значение как долго они работают, они никогда не создадут что-то так же хорошо, как это делают великие программисты. Пять Антонио Сальери не смогут создать «Реквием» Моцарта. Никогда. Даже, если они будут работать над этим 100 лет.