Испытывайте ваше приложение в реальных условиях

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

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

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

Не нужно никаких бета-версий. Версия должна быть одной. Бета-версия допускает поверхностное использование, а реальная версия получает полное и реальное использование.

Разделяйте

Сокращайте время разработки, разбивая месяцы на недели. Если проект требует 12 недель работы, разбейте его на 12 небольших кусков;. Если проект требует 30 часов работы, разбейте на куски по 6-10 часов и делайте каждый шаг за один раз, за один день.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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