Getting Real
Шрифт:
Нет страшнее яда для производительности, чем встреча. У этого несколько причин:
* Встречи разбивают рабочий день на отдельные куски и этим прерывают ваш естественный технологический процесс.
* Встречи — это всего лишь слова и абстрактные понятия.
* Встречи несут безнадежно мало полезной информации в минуту.
* На встречах часто присутствует один слабоумный, который неизбежно заставляет всех тратить на него общее время.
* У встреч есть повестки дня, такие неопределенные, что часто никто действительно не уверен в том, что надо обсуждать.
* Встречи требуют большой подготовки, чего почти никто не делает.
Если все-таки вы не можете
* Встреча должна быть не более 30 минут. Установите таймер, после 30 минут прерывайте встречу.
* Пригласите как можно меньше участников.
* Никогда не участвуйте во встрече без ясной повестки дня.
Находите и празднуйте маленькие победы
Выпустите что-нибудь сегодня
Самое главное в разработке программного обеспечения — мотивация. Сначала мотивация, потом возможности. Только с мотивацией можно сделать что-то действительно хорошо.
Долгие, затянутые циклы разработки — убийцы мотивации. Это слишком долгое время между празднованием побед. Быстрые победы — факторы мотивации. Если вы допускаете длинные циклы разработки — вы убиваете мотивацию. И это может убить ваш продукт.
Среди многих месяцев разработки посвятите один день в неделю для маленькой победы. Спросите себя: «Что можно сделать и выпустить за 4 часа?». Затем сделайте это.
Это может быть:
* Новая простая особенность
* Маленькая доработка существующей особенности
* Написание некоторого текста помощи, чтобы сократить бремя поддержки
* Удаление нескольких полей форм, которые вам действительно не нужны
Когда вы делаете что-то за 4 часа до конца, вы можете каждый раз праздновать победу. Это создает хорошее моральное состояние, увеличивает мотивацию и подтверждает, что команда движется в правильном направлении.
Персонал
Нанимайте меньше. Нанимайте позже
Добавляйте медленнее, чтобы двигаться быстрее
Нет необходимости становиться большими рано — так же как и поздно. Даже если у вас есть доступ к сотне лучших людей, это все равно плохая идея попробовать нанять их всех одновременно. Нет никакого способа, с помощью которого вы смогли бы сразу объединить столь много людей в гармоничный коллектив. Вы неизбежно столкнетесь с головной болью обучения, межличностными конфликтами, непониманием в общении, людьми с разными направлениями мышления и многим другим.
Так что не нанимайте. Серьезно, не нанимайте никого. Взгляните на это с другой стороны — действительно ли работа, которая вас отягощает, так необходима? Что случиться, если вы просто её не сделаете? Можете ли вы решить проблему с данной частью системы другим способом?
Каждый раз когда Jack Welch (former CEO of GE) увольнял кого-либо, он не нанимал человека взамен сразу. Он хотел посмотреть как долго GE может обходиться без данной персоны и его роли. Конечно, мы не призываем увольнять людей, чтобы проверить эту теорию, но мы думаем, что Jack настаивал на чём-то вроде: «Вам не нужно столько людей, сколько вам кажется необходимым».
Если нет никакого другого варианта — рассмотрите возможность найма нового человека. Но вы должны точно знать кто вам нужен, как вы введёте его в работу и как много головной боли обретёте.
Привлечение
Хороший одиночный программист, работающий над отдельной задачей, не имеет над собой проблем координации работы и общения. Пять программистов, работающих над той же задачей, обязаны общаться и координировать свои действия между собой. Это занимает много времени... Основная проблема с использованием группы посредственных программистов вместо парочки хороших состоит в том, что не имеет значение как долго они работают, они никогда не создадут что-то так же хорошо, как это делают великие программисты. Пять Антонио Сальери не смогут создать «Реквием» Моцарта. Никогда. Даже, если они будут работать над этим 100 лет.
Проверяйте
Назначайте потенциальным работникам испытательный срок
Одно дело рассматривать портфолио, резюме, примеры кода или предыдущую работу кого-либо. Другое — поработать с ним в реальных условиях. Всегда, когда это возможно, назначайте потенциальному новому члену команды тестовое задание.
Прежде чем мы нанимаем кого-либо, мы даем ему на пробу небольшой проект. Мы смотрим, как он ведёт проект, как общается, как работает и т.д. Наблюдение за тем, как человек проектирует или кодирует несколько страниц, даст вам множество информации для понимания того, подходит он вам или нет.
Сроки для подобных вещей могут быть сжатыми, но даже если это задание на 20 или 40 часов — это лучше, чем ничего. Соответствует ли вам человек или нет — это будет очевидно. И если нет — то обе стороны оберегут друг друга от множества проблем и рисков, проиграв возможную ситуацию наперёд.
Попробуйте для начала дать небольшое тестовое задание. Не надо набрасываться сразу со всей вашей работой. Дайте вашему новому виртуальному помощнику (virtual assistant, VA) один или два проекта для проверки и посмотрите, как налаживается с ним взаимопонимание. В самом начале может показаться легким закрыть глаза на потенциальные проблемы, но помните - это проверочный забег.
11
http://www.promotionworld.com/promotion/articles/findperfectva.html
Не по словам, а по делам
Ищите потенциальных работников среди разработчиков проектов с открытым кодом
Типичный метод приёма на работу технических специалистов — тот, при котором рассматривается научная степень, резюме и т. д. — слаб по многим причинам. Так уж важно кто где учился или средний бал успеваемости? Вы реально поверите тому, что написано в резюме или рекомендациях?
Проекты с открытым кодом — находка для того, кто ищет техперсонал. Они дают вам возможность следить длительное время за работой того или иного специалиста.