Давно я сюда не писал.
Но в последнее время уже в который раз люди задаются вопросом, как контролировать работу удаленного разработчика.
Ну, я тот удаленный разработчик.
Нет места более отдаленного.
Мне неоднократно доводилось быть таск-менеджером, и часто этот опыт оказывался успешным.
На самом деле, чтобы комфортно работать с программистами, достаточно даже минимального понимания того, что происходит «под капотом».
Я по теме.
Основы 1. Задачи помещаются в диспетчер задач.
Письменно, а не под диктовку по телефону или скайпу.
Если вы хотите, чтобы ваш удаленный разработчик не тратил зря свое время и силы (которые он мог бы потратить на работу), то спросите его, какой диспетчер задач ему удобно использовать.
Наверняка он пользуется им уже несколько лет и может поделиться с вами полезными навыками.
Обязательно определите проблему.
Если задача большая, вместе с разработчиком разделите ее на части, совместно запишите промежуточные цели и критерии.
Работа может проходить в условиях неявных входных данных и целей, но на каждой итерации критерии успеха должны быть очевидны.
Обычная продолжительность итерации составляет одну неделю.
Максимум – три недели.
Количество задач, поставленных на итерацию, можно обсудить с разработчиком.
Просмотрите ход предыдущей итерации при планировании следующей.
2. Коммиты загружаются в удаленный репозиторий, который, как правило, имеет веб-интерфейс.
Это означает, что вы можете просматривать свой текущий прогресс в интерактивном режиме.
Для этого не нужно обладать специальными знаниями; данная работа доступна среднестатистическому менеджеру с базовыми навыками «Оператора ВМ».
Разумеется, такой режим работы требует доверительных отношений с разработчиком.
Доверия можно добиться не уговорами, а положительным опытом работы.
3. Вы можете попросить разработчика периодически делать скринкасты нового функционала, делать скриншоты или загружать результаты тестов и присылать их вам.
4. Гораздо проще и дешевле загуглить интересующий вас вопрос, прежде чем просить разработчика объяснить вам что-то голосом.
Подробности Во-первых, легко контролировать работу.
В соответствии с результатами.
Есть конкретные задачи? Есть ли четкие приоритеты? Любую проблему можно решить в течение недели.
Если задача очень большая, ее следует разбить на более мелкие фрагменты, решение каждого из которых, скорее всего, займет один рабочий день.
Таким образом, эффективность контроля напрямую зависит от качества постановки задачи.
Во-вторых, мы, программисты, делаем модули.
На 10 средних модулей приходится примерно от 5 до 10 сложных задач и 90 совсем тривиальных.
В течение недели можно сделать от 3 до 10 модулей.
Днем – от нуля до 5. Сейчас попробую объяснить, почему это так.
Тривиальные задачи часто бывают объемными.
Их легко программировать и их программирование даже можно автоматизировать, но именно из-за их однообразия их отладка занимает больше времени.
В целом отладка занимает 60% рабочего времени.
И это нормально.
60% времени на то, чтобы заставить работать свеженаписанный код и получить от него желаемые свойства, включая производительность и безопасность (если есть дополнительные требования по этому поводу).
Сложные проблемы несколько выходят за рамки основного направления.
Сложный не значит объемный.
Просто решения этой конкретной проблемы в нынешних условиях пока не найдено.
Или было, но портирование занимало много времени или было нецелесообразно по другим причинам.
Обычно функции в удачной реализации имеют небольшой размер, буквально одну-две сотни строк.
Но это успешное решение еще предстоит найти.
На принятие решения может уйти от одного до трех дней или больше.
«эксперименты, тесты, пробы и абсолютные ошибки».
Часто без немедленных результатов.
Более эффективный способ — вообще отдохнуть от компьютера и подумать о задачах на свежем воздухе.
Увлекаюсь рыбалкой и столярным делом на даче.
Лучшее, что я придумал, приходило в голову на расстоянии нескольких десятков километров от компьютеров.
Будучи близко знаком с десятками коллег, я неоднократно обсуждал с ними этот вопрос.
Все это испытали и все понимают, что это нормально.
Именно поэтому нет смысла требовать от разработчика присутствия в режиме реального времени и использования онлайн-инструментов контроля.
Он будет присутствовать, но будет ли он продуктивен? Вот в чем вопрос.
У меня есть много друзей-руководителей, которые рассказывали похожие истории о программистах, которые носят на работу костюмы и часы, но на самом деле они работают медленно и слишком часто делают «неправильные вещи».
В-третьих, консультировать сложнее, чем разрабатывать программы.
И дело тут вовсе не в интровертном характере работы.
Консультирование – трудная работа.
Если вы хотите получить качественный результат, не нужно часами тратить мозги на глупые вопросы и обсуждения.
Если вы не компетентны в каких-то вопросах, виноват ли в этом разработчик? Хотите получить новые знания? Почему мы должны платить за ваше обучение своим временем? Если вы хотите получить качественную консультацию, подготовьтесь к ней.
Запишите вопросы в список и отправьте их по электронной почте в конце недели.
Не нужно звонить и спрашивать их по одному.
Если вы нашли ответы на вопросы, удалите их из списка.
Список пуст? Поразительнй.
Так что говорить особо не о чем.
И это тоже нормально.
Обычно программисты работают небольшими сессиями по 2-4 часа.
Таким образом, в течение дня получается всего 2 или 3 сеанса.
Если отвлечь спонтанным звонком, полдня потеряно.
Программисты работают напрямую со своим мозгом, поэтому им требуется деликатное общение.
Не стоит взорвать им мозг разговорами.
То, что вам кажется впечатляющим и убедительным, вашему собеседнику может показаться глупым и скучным.
Обычно это разговоры о перспективах, сотрудничестве, новых и старых технологиях.
Наоборот, будет интересно обсудить реальный пользовательский опыт и конкретные планы.
Независимо от того, помните вы свои звонки или нет, вы влияете на работу удаленного разработчика.
Вы также можете повлиять положительно.
Все просто: регулируйте общение и не делайте заведомых глупостей, оправдываясь оговоркой «Я этого не понимаю».
Либо разбирайтесь, либо честно сформулируйте понятные вам критерии.
Теги: #Управление проектами #программисты #программирование #Управление проектами #Управление персоналом
-
5G Для Железных Монстров
19 Oct, 24 -
Используемое Оборудование
19 Oct, 24 -
Railsclub 2016: Интервью С Заком Бриггсом
19 Oct, 24 -
Гянджа
19 Oct, 24 -
Матрица
19 Oct, 24
