egorius

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

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

Во-первых, если нельзя мотивировать, то можно помочь мотивироваться. Это сложно, но возможно, и именно так я понимаю смысл слова «мотивировать».

Во-вторых, если мотивировать сложно или даже невозможно, то демотивировать — проще простого. И, по наблюдениям, значительно чаще надо просто не демотивировать, нежели мотивировать.

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

«Избранные произведения Леонардо да Винчи»

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

Вот, например, в прекрасном рассказе «Сода-солнце» Михаила Анчарова говорится о том, что Московский Кремль проектировал малоизвестный Пьетро Антонио Солари, который, оказывается, был учеником Леонардо да Винчи, построившего Миланский Кремль:

Но почему именно ученик? Мало ли в Милане жило мастеров в то время, как Леонардо строил Кремль? Да и Леонардо не один его строил. Нужно хоть какое-нибудь прямое доказательство. Представьте себе — оно было.

Если вы пройдете у стены, которая тянется вдоль Москвы реки, то на самом верху ее вы обнаружите странные отверстия. Странные они потому, что они не в зубцах, как обычно, а между зубцами, ниже их подножия. Зубцы — это не украшения: за ними стояли воины, а в отверстия они лили кипяток и смолу. А тут отверстия находятся между зубцами, в кирпичном барьерчике, за которым даже лежать нельзя — такой он низенький. Бессмысленных отверстий в крепостной стене быть не может.

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

И действительно, есть такой рисунок!

P. S. Не откажу себе в удовольствии сослаться и на другой рассказ — труды Леонардо хранят еще много тайн для пытливых умов.

Jared Richardson, William Gwaltney Jr., «Ship It! A practical guide to successful software projects»

Авторы делятся теми практиками и инструментами, которые, по их опыту, неизменно подтверждают свою пользу и эффективность. Мне показалось интересным сравнить их предложения с тем, что используется у нас в компании.

• Разработка в «песочнице» — каждый разработчик ведет разработку так, чтобы не мешать другим
  У нас про это говорят с иронией: «каждому разработчику по инстансу». Увы, система слишком велика и прожорлива, чтобы оправдать поддержку такого количества сред. Но по возможности, конечно, стараемся не мешать друг другу.
• Система контроля версий
  Да, конечно. Хотя я еще помню смутные времена, когда исходный код был только в базе.
• Автоматизированная сборка
  У нас нет такого понятия, как сборка. Система не пересобирается, изменения выкатываются на нее в виде патчей. А вот процесс сборки патчей — да, практически автоматизирован. Хотя тут есть еще над чем поработать.
• Автоматическая сборка — a.k.a. непрерывная интеграция и тестирование
  Сборка у нас лишена смысла, см. выше. Вот что не лишено смысла, так это тестирование. Даже те немногочисленные тесты, которые у нас есть, никто никогда не прогоняет, и теперь я понимаю, как это исправить. Надо прогонять их автоматически после перекомпиляции любого объекта в базе данных! Надо подумать, как это сделать технически, в частности, отправку результатов почтой.
• Ведение задач и дефектов
  Да, JIRA. К сожалению, в JIRA невозможно заниматься планированием, поэтому много времени уходит впустую на перекладывание из Excel или Project в JIRA и потом поддержание в ней актуального состояния. Как с этим бороться — не знаю.
• Ведение требований
  Да. Чаще всего это Excel, но в последнее время пытаемся вести в JIRA.
• Автоматические тесты
  Тут наше слабое место, тесты мы практически не пишем. Во-первых, платить предпочитают за поддержку, а не за отсутствие дефектов, а во-вторых есть технические трудности.
• Список (с большой буквы) — перечень задач: выложен на видное место; приоритезирован; с временными оценками; отражает реальную текущую картину; содержит пункты, про которые можно точно сказать «выполнен» или «не выполнен»; предназначен как для всей команды, так и для каждого в отдельности
  Раньше был действительно Список в Excel, но он не был «выложен на видное место» и работал плохо. Сейчас это JIRA. Над приоритезацией надо подумать: сейчас мы ориентируемся скорее на предполагаемую дату готовности, чем на приоритет как на таковой.
• Технический тимлид
  Да, хотя у авторов этот человек выполняет роли как нашего технического тимлида, так и функционального. Возможно, объединить их и имеет смысл, но где взять таких мегамонстров?
• Ежедневные общие встречи
  Мы практикуем еженедельные встречи (по времени порядка часа). На мой взгляд, это оправдано, поскольку в наших реалиях задачи и код пересекаются не настолько, чтобы встречаться ежедневно. Авторы сильно агитируют, но я не проникся.
• Ревью кода
  У нас ревью в основном делают тимлиды, и происходит это после коммита в репозиторий кода. Авторы предлагают, чтобы ревью делали все (над этим надо подумать, но пока не вижу, как это организовать с пользой) и чтобы в комментарии к коммиту стояло имя ревьюера (у нас коммит не ломает сборку, так что не страшно). Ценная мысль: ревьюить небольшие изменения, не доводя до того, что придется пересматривать тысячи строк кода.
• Рассылка изменений в коде
  Нет, но идея интересная. Надо подумать, как это сделать, и попробовать на практике.

Эдвард Йордан, «Путь камикадзе: как разработчику программного обеспечения выжить в безнадежном проекте»

На эту книгу часто ссылаются (в том числе и авторы Ship It!), а я, хоть и читал ее когда-то, ничего не запомнил, кроме отвращения от перевода и типографики. Не то, чтобы сейчас я стал терпимей к издательству Лори, но появился кое-какой опыт, на который эта книга хорошо ложится. Йордон определяет безнадежный проект, как тот, которому не хватает как минимум 50% какого-либо ресурса, и рассуждает о 90-часовых рабочих неделях. У нас нет «безнадежных проектов» в таком смысле, но 10-20% и 50-60 часов — это сплошь и рядом. А от сгущения красок картина видна только яснее, отмасштабировать потом всегда можно.

Особенно вправляет мозг глава «Безнадежные проекты как образ жизни», после которой не остается сомнений в том, что в следующем проекте опять не обойдется без переработок — это просто корпоративная политика ведения бизнеса.

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

• Формальное управление рисками
  Вот это несколько мутная для меня тема. Надо будет почитать что-нибудь.
• Планирование, основанное на данных, полученных в предыдущих проектах
  С этим плохо, таких данных обычно просто нет, и не очень понятно, как их собирать — проекты-то все разные.
• Двоичная оценка завершенности — «да» или «нет»
  Стараемся, но иногда, если не уследить, казалось бы по завершенной задаче начинают меняться требования и пошло-поехало. Это надо пресекать.
• Ежедневная сборка проекта
  Йордон имеет в виду ежедневную готовность к сдаче работы, и в таком смысле эту идею надо обдумать. Сейчас у нас более длинные циклы и я не уверен в необходимости их укорачивания.

И еще пара ценных мыслей:

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