Текст книги "Getting Real"
Автор книги: 37signals
Жанр:
Программирование
сообщить о нарушении
Текущая страница: 4 (всего у книги 8 страниц)
Сокращайте время
Разделяйте
Сокращайте время разработки, разбивая месяцы на недели. Если проект требует 12 недель работы, разбейте его на 12 небольших кусков;. Если проект требует 30 часов работы, разбейте на куски по 6-10 часов и делайте каждый шаг за один раз, за один день.
Вы сталкиваетесь с большой проблемой, которую уже не в состоянии держать в голове. Разделите ее на кусочки, каждый из которых сможете обдумать с легкостью и решить за один шаг.
Организация
Единство
Не разделяйте лишний раз
У многих компаний такие направления как проектирование, развитие, копирайтинг, поддержка, маркетинг разделены на отделы. Такая специализация по отделам, конечно, имеет свои преимущества, но также создает ситуацию, когда сотрудники видят только свой маленький мир, а не полный контекст веб-приложения.
Как можно больше смешивайте команду по различным специализациям, так чтобы наладить диалог между всеми в процессе работы. Не позволяйте чему-то теряться из-за отсутствия диалога в команде. Пусть копирайтеры работают над текстом вместе с проектировщиками. Убедитесь, что разработчики видят, как работает поддержка.
Еще лучше нанять людей с разными талантами, которые они будут применять в течение всей работы над проектом. Результатом будет более гармоничный продукт.
Единое время
Людям нужно время, чтобы постоянно добиваться своего
Сотрудники 37signals находятся в четырех городах и в восьми часовых поясах. От Прово, штат Юта до Копенгагена, Дания. Есть только 4-5 часов в течение дня, когда мы работаем вместе. Когда наша команда спит, Давид, который находится в Дании, работает. Мы работаем, Давид спит. Это дает нам только половину дня для совместной работы.
Можно предположить, что и время работы, и эффективность от работы сокращается вдвое. Но это нет так.
Известно, что многие люди предпочитают работать рано утром или поздно вечером – это время когда их не беспокоят, это время самое продуктивное для них. Это время становится таким, потому что никто не прерывает работу, и никто не отвлекает.
Поэтому можно установить правило: сделать половину рабочего дня единым временем для работы. В это время не отвлекаться на телефонные звонки, чтение почты, ненужное общение с коллегами и т.д.
Избегайте любых перерывов во время единого времени работы. Каждый перерыв снижает производительность и отвлекает настолько, что потом опять необходимо вникать в работу. Это все снижает продуктивность и увеличивает количество часов, требуемых для выполнения работы.
Встречи ядовиты
Никаких встреч
Вам действительно нужны встречи? Встречи обычно возникают, когда что-то не достаточно ясно. Вместо встречи, попытайтесь упростить обсуждение и воспользуйтесь мессенджером или Campfire. Минута встречи крадет минуту реальной работы. Поставьте себе цель – избегать встреч.
Нет страшнее яда для производительности, чем встреча. У этого несколько причин:
* Встречи разбивают рабочий день на отдельные куски и этим прерывают ваш естественный технологический процесс.
* Встречи – это всего лишь слова и абстрактные понятия.
* Встречи несут безнадежно мало полезной информации в минуту.
* На встречах часто присутствует один слабоумный, который неизбежно заставляет всех тратить на него общее время.
* У встреч есть повестки дня, такие неопределенные, что часто никто действительно не уверен в том, что надо обсуждать.
* Встречи требуют большой подготовки, чего почти никто не делает.
Если все-таки вы не можете избежать встречи (что должно быть очень редким событием), воспользуйтесь простыми правилами:
* Встреча должна быть не более 30 минут. Установите таймер, после 30 минут прерывайте встречу.
* Пригласите как можно меньше участников.
* Никогда не участвуйте во встрече без ясной повестки дня.
Находите и празднуйте маленькие победы
Выпустите что-нибудь сегодня
Самое главное в разработке программного обеспечения – мотивация. Сначала мотивация, потом возможности. Только с мотивацией можно сделать что-то действительно хорошо.
Долгие, затянутые циклы разработки – убийцы мотивации. Это слишком долгое время между празднованием побед. Быстрые победы – факторы мотивации. Если вы допускаете длинные циклы разработки – вы убиваете мотивацию. И это может убить ваш продукт.
Среди многих месяцев разработки посвятите один день в неделю для маленькой победы. Спросите себя: «Что можно сделать и выпустить за 4 часа?». Затем сделайте это.
Это может быть:
* Новая простая особенность
* Маленькая доработка существующей особенности
* Написание некоторого текста помощи, чтобы сократить бремя поддержки
* Удаление нескольких полей форм, которые вам действительно не нужны
Когда вы делаете что-то за 4 часа до конца, вы можете каждый раз праздновать победу. Это создает хорошее моральное состояние, увеличивает мотивацию и подтверждает, что команда движется в правильном направлении.
Персонал
Нанимайте меньше. Нанимайте позже
Добавляйте медленнее, чтобы двигаться быстрее
Нет необходимости становиться большими рано – так же как и поздно. Даже если у вас есть доступ к сотне лучших людей, это все равно плохая идея попробовать нанять их всех одновременно. Нет никакого способа, с помощью которого вы смогли бы сразу объединить столь много людей в гармоничный коллектив. Вы неизбежно столкнетесь с головной болью обучения, межличностными конфликтами, непониманием в общении, людьми с разными направлениями мышления и многим другим.
Так что не нанимайте. Серьезно, не нанимайте никого. Взгляните на это с другой стороны – действительно ли работа, которая вас отягощает, так необходима? Что случиться, если вы просто её не сделаете? Можете ли вы решить проблему с данной частью системы другим способом?
Каждый раз когда Jack Welch (former CEO of GE) увольнял кого-либо, он не нанимал человека взамен сразу. Он хотел посмотреть как долго GE может обходиться без данной персоны и его роли. Конечно, мы не призываем увольнять людей, чтобы проверить эту теорию, но мы думаем, что Jack настаивал на чём-то вроде: «Вам не нужно столько людей, сколько вам кажется необходимым».
Если нет никакого другого варианта – рассмотрите возможность найма нового человека. Но вы должны точно знать кто вам нужен, как вы введёте его в работу и как много головной боли обретёте.
Закон Брукса
Привлечение людей к просроченному проекту задержит его ещё больше.
– Fred Brooks
Программирование и «Реквием» Моцарта
Хороший одиночный программист, работающий над отдельной задачей, не имеет над собой проблем координации работы и общения. Пять программистов, работающих над той же задачей, обязаны общаться и координировать свои действия между собой. Это занимает много времени... Основная проблема с использованием группы посредственных программистов вместо парочки хороших состоит в том, что не имеет значение как долго они работают, они никогда не создадут что-то так же хорошо, как это делают великие программисты. Пять Антонио Сальери не смогут создать «Реквием» Моцарта. Никогда. Даже, если они будут работать над этим 100 лет.
– Joel Spolsky, software developer, Fog Creek Software (from Hitting the High Notes)
Проверяйте
Назначайте потенциальным работникам испытательный срок
Одно дело рассматривать портфолио, резюме, примеры кода или предыдущую работу кого-либо. Другое – поработать с ним в реальных условиях. Всегда, когда это возможно, назначайте потенциальному новому члену команды тестовое задание.
Прежде чем мы нанимаем кого-либо, мы даем ему на пробу небольшой проект. Мы смотрим, как он ведёт проект, как общается, как работает и т.д. Наблюдение за тем, как человек проектирует или кодирует несколько страниц, даст вам множество информации для понимания того, подходит он вам или нет.
Сроки для подобных вещей могут быть сжатыми, но даже если это задание на 20 или 40 часов – это лучше, чем ничего. Соответствует ли вам человек или нет – это будет очевидно. И если нет – то обе стороны оберегут друг друга от множества проблем и рисков, проиграв возможную ситуацию наперёд.
Начните с малого
Попробуйте для начала дать небольшое тестовое задание. Не надо набрасываться сразу со всей вашей работой. Дайте вашему новому виртуальному помощнику (virtual assistant, VA) один или два проекта для проверки и посмотрите, как налаживается с ним взаимопонимание. В самом начале может показаться легким закрыть глаза на потенциальные проблемы, но помните – это проверочный забег.
Не по словам, а по делам
Ищите потенциальных работников среди разработчиков проектов с открытым кодом
Типичный метод приёма на работу технических специалистов – тот, при котором рассматривается научная степень, резюме и т. д. – слаб по многим причинам. Так уж важно кто где учился или средний бал успеваемости? Вы реально поверите тому, что написано в резюме или рекомендациях?
Проекты с открытым кодом – находка для того, кто ищет техперсонал. Они дают вам возможность следить длительное время за работой того или иного специалиста.
Это значит, вы можете оценивать людей по-сделанному, а не по-сказанному. Вы сможете принимать решение основываясь на действительно важных факторах:
качество работы
Некоторые программисты могут красочно «заливать» о своих способностях, но при этом «съезжать с темы» когда доходит до дела. Участие человека в открытых проектах покажет суть его умений и опыта.
воззрения
Программирование это постоянное принятие решений. Огромного их количества. Решения зависят от воззрений, ценностей и идеалов. Присмотритесь к тем решениям, которые принял потенциальный кандидат при разработке кода, тестировании, в спорах, чтобы понять, в какой мере его представления соответствуют вашим. Если эта мера мала, вам будет трудно принимать решения вместе.
уровень увлеченности
Определенно, участие в открытых проектах требует хоть малость увлеченности. Иначе, зачем человек тратит время сидя за монитором? Степень занятости в открытых проектах часто показывает насколько человек действительно любит программировать.
умение довести дело до конца
Ни самые мудрые и правильные воззрения, ни огромнейшая увлеченность не стоят ничего, если кандидат не может довести дело до конца. К сожалению, это дано не всем. Ищите тех кто может. Нанимайте человека, который доводит дело до конца, во что бы не стало; но в тоже время, способного находить прагматичные компромиссы.
умение работать в коллективе
Работая с кем либо долгое время, проходя через взлёты и падения, стрессы и «расслабоны» вы увидите реальный характер человека. Даже не обращайте внимания на тех, кто не обладает достаточной сдержанностью, или щедро наделён несносными манерами.
Когда речь идет о программистах, мы нанимаем только тех, кого мы знаем по проектам с открытыми исходниками. Считаем остальные подходы несостоятельными. Мы пригласили Джеймиса заметив его участие в разработках сообщества Ruby. Он выделялся среди остальных. Не было необходимости рассматривать второстепенные факторы, поскольку мы могли оценить его работу по главному критерию – качеству.
Не переживайте если какие-либо внештатные увлечения отвлекают ваших сотрудников от их основной работы. Перефразируя избитое выражение: если хочешь, чтобы дело было сделано хорошо, доверь его самому занятому человеку. Дэвид и Джеймис самые активные разработчики Rails и все еще успешно справляются с техническими вопросами в 37signals. Вашей команде нужны те, кто обожает программирование и умеет довести начатое до конца.
Увлеченные программированием
Что вы больше всего хотите от недавно нанятого человека? Конечно увлеченности своим делом. И нет лучшего способа увидеть это, чем посмотреть на участие человека в открытых проектах.
Нанимайте эрудитов
Быстро обучающиеся универсалы лучше закостенелых авторитетов
Мы никогда не наймем кого-либо, чья профессия называется «разработчик структуры системы программного обеспечения». Это уж слишком. В маленьких командах, таких как наша, нет смысла в подобного рода узких специалистах.
В маленьких командах нужны мастера «на все руки». Дизайнеры, умеющие вести техническую документацию. Программисты, сведущие в вопросах дизайна. Каждый должен себе представлять какой должна быть структура системы (какой бы смысл вы бы не вкладывали в это понятие). Каждому нужно мыслить системно. Каждый должен уметь общаться с клиентами. И, в случае необходимости, каждый должен уметь, резко «дав по тормозам», развернуться контролируемым заносом. Запомните, маленьким командам иногда надо изменить направление и сделать это быстро. Вам нужен тот, кто сможет учиться, привыкать, приспосабливаться, а не закостенелый брюзга, специализирующийся на чём-то одном.
Неподдельный энтузиазм
Берите счастливых середнячков, а не разочаровывающих гуру
Энтузиазм. Свойство, не передающееся даже самым умелым притворством. Пришло время нанять кого-то в команду? Не думайте, что нам нужен гуру или хорошо известный (в тесных кругах) специалист. Такие всё равно чаще всего выступают в роли «свадебных генералов». Счастливый специалист средней руки лучше раздражённого эксперта.
Берите того, у кого есть энтузиазм. Того, кому вы доверите остаться самому и доделать работу. Того, кто страдал в больших и неповоротливых компаниях и жаждет новой обстановки. Того, кому нравиться делать то же что делаете вы. Того, кто ненавидит то же, что и вы. Того, у кого учащается дыхание, когда он взбирается на борт вашего корабля.
Дополнительные баллы тем, кто спрашивает
Обратите внимание, задает ли соискатель вопросы о вашем проекте. Увлеченные программисты хотят максимально разобраться в проблеме и готовы сразу предложить потенциальные решения или улучшения, – и поэтому много спрашивают. Разбирая вопросы, вы также поймете, что проект можно реализовать сотнями способов и очень важно точно, с предельной чёткостью выразить своё видение того, как будет работать ваше веб-приложение. По мере того, как вы углубляетесь в детали, вы всё больше чувствуете на сколько опыт и характер человека соответствуют вашей команде.
Мастера Слова
Нанимайте хороших писателей
Если вы задумываетесь над тем, какого рода специалиста можно еще пригласить на не занятое место, – наймите того, кто лучше других умеет вести документацию. Не важно кто он – дизайнер, программист, специалист по продажам или кто-то еще, его умение хорошо писать окупится с лихвой. Понятная, последовательная документация ведет к понятному и последовательному коду, дизайну, письмам, объявлениям и т. д.
Хороший писатель не просто тот, кто грамотен. Хорошие писатели знают как донести суть. Они делают сложное – понятным. Они умеют посмотреть на вещи «непонимающим» взглядом. Они знают что лишнее. Их мысли ясны. И они те, кто вам нужен.
Светлый Разум
Умение хорошо писать – показатель того, насколько организован человек; способен ли он упорядочивать, систематизировать и подавать информацию так, чтобы другим было легче её понять. Это сказывается на коде, общении, чатах (для коллективов которые работают удаленно) и даже на таких сокровенных понятиях как профессионализм и надежность.
Письмо упорядочивает мысли
Отчетливое письмо делает отчётливее и мысли. Вы не знаете что именно вы знаете пока вы не выразите это. Умение понятно писать – это, в некоторой степени, черта характера. Вместо того, что упрощать что-то для себя, упростите это для своих читателей.
Создание интерфейса
Сначала – интерфейс
Создавайте дизайн интерфейса до того как начнете программировать
Слишком много приложений создаются с подходом «сначала программируем». Это неудачная идея. Программирование – самое сложное в создании приложения, а это значит, что и самое дорогое. И, создав код, вам будет сложно его изменить. Вместо этого начинайте с дизайна интерфейса.
Дизайн относительно легко изменять. Бумажный набросок дешев и его легко изменить. html-наброски тоже довольно просто изменить или просто выбросить. Но в отношении программирования это неверно. Подход «сначала дизайн» позволит вам быть гибкими. Подход «сначала программирование» ограничивает вас и приводит к дополнительным затратам.
Другая причина для того, чтобы начинать с дизайна в том, что интерфейс и есть продукт. Вы продаете людям то, что они видят. И если вы оставите интерфейс «на потом», огрехи будут заметны.
Мы начинаем с интерфейса, и можем «пощупать» приложение с самого начала. И интерфейс постоянно пересматривается в процессе разработки. Понятен ли он? Прост ли в использовании? Позволяет ли легко решить проблему? Верно ответить на эти вопросы вы можете только если уже имеете реальный интерфейс. Подход «сначала дизайн» позволяет вам оставаться гибкими и подталкивает к ответам на эти вопросы как можно раньше, вместо того что бы оставлять их «на потом».
Оранжевая ручка, с которой начался Blinksale
Как только я понял, что готовые приложения для выставления счетов меня не устраивают, я решил нарисовать на бумаге, как я представляю такое приложение. Я взял оранжевую ручку, потому что больше в тот вечер было нечем рисовать, и через несколько часов три четверти будущего приложения были готовы. Я показал всё своей жене, Рейчл, которая как раз гладила и спросил её, что она думает по этому поводу. И она ответила с улыбкой: «Тебе надо сделать это. Правда.»
Следующие две недели я дорабатывал дизайн, и сделал статические наброски для всех страниц первой версии того, что потом стало называться Blinksale. Мы никогда не делали никаких каркасов кроме тех набросков оранжевой ручкой, и то, что мы перешли сразу к html-страницам, подстёгивало нас, так как проект становился более реальным, хотя в то время мы и не знали что именно происходит.
Как только html-макеты были готовы, мы рассказали идею нашему разработчику, Скотту. То, что большая часть дизайна была уже создана, было весьма кстати. Во-первых, это дало Скотту реальной представление о направлении, в котором мы движемся, и вовлекло его. Это было больше чем идея, это была реальность. Во-вторых, это помогло нам подсчитать, сколько усилий и времени потребуется от Скотта, чтобы превратить дизайн в работающее приложение. Когда вы финансируете проект с самого начала, то чем раньше вы сможете предсказать бюджет тем лучше. Дизайн пользовательского интерфейса стал нашим мерилом для границ проекта. И последнее – дизайн интерфейса служил нам для того, чтобы напомнить нам о том, для чего предназначено приложение, по мере того, как продвигалась разработка. Каждый раз как появлялся соблазн добавить новые возможности, мы не могли просто сказать «А давайте-ка добавим вот это и ещё это!». Мы должны были бы вернуться к дизайну и спросить себя, где надо добавить новую возможность, и если для неё не было места, мы её не добавляли
Дизайн от эпицентра
Начинайте с самого важного на странице и двигайтесь вширь
Дизайн от эпицентра фокусирует внимание на том, что наиболее важно на странице, а затем обращается к менее важному. Это значит, что сначала вы игнорируете то что находится кругом – навигацию, закладки, «подвал» страницы, цвета, логотип и так далее. Вместо этого, вы начинаете с эпицентра и сначала разрабатываете наиболее важную часть страницы.
Без чего страница абсолютно не может быть – это без эпицентра. К примеру, если вы разрабатываете страницу, которая показывает пост в блоге, пост – это и есть эпицентр. Не категории в сайдбаре, не заголовок страницы, не форма комментариев внизу, а именно пост. Без поста эта страница бессмысленна.
Только когда эпицентр готов, можно подумать о втором по критичности элементе на странице. После второго вы можете перейти к третьему и так далее. Это и есть дизайн «от эпицентра».
Дизайн от эпицентра избегает традиционной модели «давайте построим раскладку, потом засунем туда контент». В этом процессе строится общая форма страницы, потом добавляется навигация, потом маркетинговое барахло, и потом, наконец, основная функциональность, то, для чего страница предназначена, впихивается на оставшееся место. Это перевернутый процесс в котором наиболее приоритетные вещи откладываются на потом.
Дизайн от эпицентра переворачивает этот процесс и позволяет вам сфокусироваться на том, что важно, в первый день. Основное – сначала, дополнения – потом. В результате получается более дружественный, ориентированный на пользователя, удобный в использовании экран для клиентов. Плюс, это позволяет вам начать диалог между дизайнером и разработчиком прямо сейчас вместо того чтобы ждать пока все аспекты страницы будут проработаны.
