[recovery mode] Взгляд изнутри на удаленную разработку, или почему программирование — процесс не линейный
Давно ничего не писал. Но за последнее время на тостере уже в который раз спрашивают, как контролировать работу удаленного разработчика.
Что ж, я — тот самый удаленный разработчик. Удаленнее некуда.
Мне много раз приходилось бывать и в роли постановщика задач, и зачастую этот опыт был успешным. На самом деле, для комфортной работы с программистами достаточно даже минимального понимания того, что происходит «под капотом».
Палю тему.
1. Задачи ставятся в таск-менеджер. В письменном виде, а не диктуются по телефону или скайпу.
Если вы хотите, чтобы ваш удаленный разработчик не тратил свои силы и время (которые он мог бы направить на работу), то спросите у него, какой таск-менеджер ему удобно использовать. Наверняка он обоснованно пользуется именно им несколько лет, и может поделиться и с вами полезными навыками.
Убедитесь, что вы сформулировали задачу. Если задача велика — вместе с разработчиком разделите ее на части, совместно запишите промежуточные цели и критерии. Работа может проходить в условиях неявных исходных данных и целей, но на каждой итерации критерии успеха должны быть очевидны.
Нормальная продолжительность итерации — одна неделя. Максимальная — три недели. Количество задач, выставляемых на итерацию, можно обсуждать с разработчиком. Изучите прогресс предыдущей итерации при планировании следующей.
2. Комиты заливаются в удаленный репозиторий, который, как правило, имеет веб-интерфейс. Это означает, что вы можете просматривать текущий прогресс интерактивно. Для этого не нужно иметь специальных знаний, эта работа доступна среднестатистическому менеджеру с базовыми навыками «Оператор ЭВМ». Конечно, такой режим работы требует доверительных отношений с разработчиком. Доверия можно добиться не увещеваниями, а позитивным опытом работы.
3. Можно попросить разработчика периодически делать скринкасты новой функциональности, скринить или выгружать результаты тестов и присылать вам.
4. Намного проще и дешевле пойти и погуглить интересующий вас вопрос, прежде чем просить разработчика объяснять вам что-то голосом.
Во-первых, контролировать работу просто. По результатам. Есть конкретные поставленные задачи? Есть ясные приоритеты?
Любую задачу можно решить в течение недели. Если задача сильно объемная, она должна быть разбита на меньшие фрагменты, решение каждого из которых скорее всего занимает один рабочий день.
Таким образом, эффективность контроля прямо зависит от качества постановки задачи.
Во-вторых, мы, программисты, делаем модули. На 10 среднестатистических модулей приходятся примерно от 5 до 10 сложных задач, и 90 очень тривиальных. В течении недели удается сделать от 3 до 10 модулей. В течении дня — от нуля до 5. Сейчас попробую объяснить, почему так.
Тривиальные задачи часто бывают объемными. Они легко программируются и их программирование даже автоматизируется, но именно из-за монотонности они дольше отлаживаются. Вообще, на отладку уходит 60% рабочего времени. И это нормально. 60% времени на то, чтобы заставить работать свеженаписаный код, и чтобы добиться от него нужных свойств, включая производительность и безопасность (если есть дополнительные требования в этой связи).
Сложные задачи несколько выбиваются из мейнстрима. Сложные — не значит объемные. Просто решения именно этой задачи в текущем контексте еще не было. Или было, но портировать долго или не целесообразно по иным причинам. Обычно функции в удачной реализации имеют небольшой размер, буквально одна-две сотни строк. Но до этого удачного решения нужно еще прийти.
Идти до решения можно от одного до трех дней, или дольше. Экспериментами, тестами, пробами и безусловными ошибками. Часто без мгновенного результата. Более эффективный путь — отвлекаться от компьютера вообще, и обдумывать задачи на свежем воздухе. Я увлекаюсь рыбалкой и плотничаю на даче. Лучшее из того, что я придумывал, приходило в голову на расстоянии нескольких десятков километров от компьютеров. Будучи близко знакомым с десятками коллег, много раз обсуждал с ними этот вопрос. Все сталкивались с этим, и все понимают, что это нормально.
Именно поэтому бессмысленно требовать от разработчика присутствия в реальном времени, и использования средств онлайн-контроля. Присутствовать-то он будет, но будет ли он продуктивен? Это вопрос.
У меня есть множество знакомых руководителей, которые рассказывали похожие истории про программистов, которые ходят на работу в костюме и по часам, но по факту работают медленно и слишком часто делают «не то».
В-третьих, заниматься консультированием — сложнее, чем разрабатывать программы. И дело тут вовсе не в интравертной специфике труда.
Консультирование — сложный труд. Если вы хотите получить качественный результат — не надо часами выносить мозги, глупейшими вопросами и обсуждениями. Если вы не компетентны в каких-то вопросах — есть ли тут вина разработчика? Хотите получить какие-то новые знания? А почему мы должны платить за ваше обучение своим временем?
Если вы хотите получить качественную консультацию — подготовьтесь к ней. Запишите вопросы списком и отправьте их на почту в конце недели. Не нужно звонить и задавать их по одному. Если вы нашли ответы на вопросы — удалите их из списка. Список пуст? Великолепно. Значит действительно не о чем говорить. И это тоже нормально.
Обычно программисты работают небольшими сессиями, по 2-4 часа. Таким образом, в течение дня получается провести всего 2 или 3 сессии. Если вы отвлекаете спонтанным звонком — теряется полдня. Программисты работают непосредственно мозгами, поэтому требуют несколько деликатного общения. Не стоит им беседами мозг выносить.
То, что вам кажется эффектным и убедительным, вашему собеседнику может показаться глупым и скучным. Обычно это беседы про перспективы, сотрудничество, новые и старые технологии. Напротив, интересным будет обсуждение реального пользовательского опыта и конкретных планов.
Вне зависимости от того, помните вы о своих звонках или нет — вы влияете на работу удаленного разработчика. Можете влиять и позитивно. Это просто: регламентируйте общение и не делайте осознанных глупостей, оправдываясь оговоркой «я же в этом не разбираюсь».
Или разберитесь, или честно формулируйте критерии, понятные вам.
© Megamozg
