Как контролировать работу удаленного программиста?

Question

[omgownedbygirl]

Я заказываю разработку своего сервиса у удаленного программиста. Человек при найме казался адекватным и заинтересованным. Однако со временем качество и скорость работы стали падать: простые задачи делаются неделями, сложные вообще по несколько месяцев, после сдачи спринта выявляется куча багов и ошибок. При всем при этом количество часов потраченных в месяце на разработку (за которые я плачу) не меняются, иногда даже увеличиваются.

У меня вопрос, как можно отслеживать прогресс разработки приложения на Ruby on Rails если некоторые задачи никак не связанны с фронтэндом и программист говорит, что процесс идет, просто это в коде и его не видно? Может как то по коммитам или еще как, есть ли какие ни будь статьи на эту тему и тд?

Я сама программистом не являюсь и по коду не могу оценить, потрачено было 10 минут или 10 часов.

Answer 1

[Артем Спиридонов]

Для начала, не надо было пытаться так экономить. Судя по тому, что на решение задачи тратятся месяцы - вы искали самого дешевого программиста, и с вами согласился сотрудничать новичок. Он сейчас скорее всего жалеет о том, что с вами связался. Простите, но вы сами виноваты. Семь шапок из одной овцы не выкроишь никак.

Любая задача решается не более, чем за одну неделю. Подавляющее большинство программ выпускаются в бету за 2-3 месяца. Если дольше - нужно бить тревогу. Или неправильное планирование, или проблемы в команде.

Мониторить просто - по списку задач в трекере и/или по коммитам. Не нужно ожидать, что разработчик будет выдавать какой-то прогресс ежедневно. Программирование - это не линейный процесс. Можно день-два протупить, а потом за десять минут сделать - такое происходит постоянно. Удобными для всех будут ежеденедельные итерации. Например, каждый понедельник проверять прогресс за неделю, и при необходимости, скорректировать его.

Не выносите разработчику мозги длинными беседами. У программистов мозг несколько иначе устроен, и длинными беседами вы ему мозг выносите. После чего ему работать сложно - таким образом вы сами создаете проблемы. Пишите вопросы текстом, и делайте это не чаще, чем один раз в неделю. Накапливайте вопросы, прежде чем отправить их письмом. Если вы нашли ответ на вопрос самостоятельно - удалите его из списка. Проверьте, нет ли ответов на вопросы в интернете.

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

С консультациями, как с сексом. Хотите, чтобы было качественно? Тогда нужно хорошо подготовиться. И вести себя прилично. Всегда. Хотите хорошие ответы? Продумайте свои вопросы.

В состоянии потока любая хрень может отвлечь и нарушить рабочее состояние. Особенно - вопросы. Особенно - глупые вопросы. Глупые не с вашей точки зрения, а с точки зрения разработчика. Программист работает циклами по 2-4 часа. Если нарушить цикл (например, задав глупый вопрос или позвонив по телефону) - теряется ПОЛОВИНА ДНЯ.

Поэтому мое второе замечание - проверьте, а не мешаете ли вы ему работать?

Comments

[crazywebdev]

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

[Максим Тимофеев]

+1 Я вообще скайп выключаю и в перерывах читаю, кто что писал. Потому что достали. Особенно заказчики. К тому же многие заказчики вначале пишут, а потом думают, поэтому через 5 минут может появится задача противоположная первой. Для себя определился - работаю только через тикеты (gitlab или аналоги). Тогда получается конструктивный диалог. Задачи разделены, можно по каждой задачи видеть историю и т.д.

[No_Bugs]

не любая задача решается за неделю.

Answer 2

[Пума Тайланд]

Очевидно что надо менять программиста.
Контролировать очень просто есть у каждой задачи деадлайн и по нему легко контролировать, ну и смотреть историю в гите.

Comments

[Максим Тимофеев]

А кто дедлайн определяет? А если заказчик 15 раз в процессе меняет эту задачу? Самый правильный способ таймер. Сам работаю почасово. Я доволен, заказчики довольны. Я получаю, что заслужил, заказчик получает картину, почему это так стоит.

[Пума Тайланд]

Максим Тимофеев: кто то определяет.
Это вообще другая проблема, тут обсуждается плохой программист, а не плохой заказчик.
В данном случае проблемы не у программиста, а не у заказчика.

[omgownedbygirl]

Дедлайны постоянно срываются, но я как не самая опытная в этом деле, могу предположить, что задачу N делать 1 день, а на самом деле 1 неделю. Те ДЛ которые определяет он, также в большинстве своем затягиваются и объясняется это непредвиденными сложностями.

[Максим Тимофеев]

Заказчик может думать, что программист плохой, при этом он может быть вполне нормальным. Заказчик не может оценить качество специалиста. Поэтому повремянка - единственный выход. И например нанять кого-то кто будет проверять работу, тратя 15 минут в день и зарабатывая лишнюю копеечку. Назовем его менеджер проекта. И будет двигаться работа. Аж свистеть.

[Пума Тайланд]

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

[Пума Тайланд]

Максим Тимофеев: обычно это не 15 минут и не зря же менеджеры забирают половину зп программистов которых манаджат.

Answer 3

[Максим Тимофеев]

платите почасово, отслеживайте время в специализированном ПО. Например: www.tahometer.com

Не вижу проблемы, вижу не знание методов.

Answer 4

[Renat Ibragimov]

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

Answer 5

[Евгений]

Можно определить график апдейтов в Git/SVN и отслеживать, что меняется.
Можно ставить задачи в чем-то типа Redmine и отслеживать их выполнение.
Можно предложить ему поставить трекер типа Timedoctor на свой компьютер и отслеживать, чем он занимается.

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

Comments

[Максим Тимофеев]

Что значит "Любое предложение по отслеживанию активности будет воспринято в штыки"
Либо так либо никак. Кто деньги платит? Фрилансеров, которые ищут где бы заработать кучи. Пинком под зад и найти того, кто будет работать с таймером.

Answer 6

[Dmitry Pavlov]

Все задачи должны быть записаны (вы можете использовать как любой таск трекер вроде JIRA, так и просто Excel файл в Dropbox, например, главное - обоим иметь доступ к списку задач). По каждой должно быть описание, что именно требуется сделать в рамках задачи. Просите разработчика оценить по времени первоочередные задачи из общего списка (также - если задачи зависимы дург от друга - расставить их в порядке выполнения) и на основе этой оценки наберите задач на неделю работы. По каждой таким образом будет заранее известна временная оценка. Она может поменяться в ходе работы, конечно, но этому изменению всегда будет понятная причина. Вы можете после оценки на неделю пробежаться вместе по списку задач и проговорить какждую (убедиться, что разработчику все ясно, сделать необходимые пояснения и тп). Это позволит сделать первичную оценку более надежной.

Попросите разработчика каждый день писать вам отчет в виде:
1) какие задачи были сделаны
2) какие задачи планируется делать дальше
3) какие есть проблемы, вопросы, сложности по текущей работе

Получая этот отчет, вы будет видеть прогресс по работе в рамках недели и сможете оценить (если сроки затягиваются), в чем проблема. Также побочный полезный эффект - вы каждый день сможете помогать разработчику, оперативно отвечая на вопросы из пункта 3.

Поддерживаю мнение о том, что задачи должны быть не слишком большие - меньше чем 8 часов (рабочий день), а лучше не более 4 часов. Большие задачи надо постараться поделить на части.

В любом приложении, как правило, есть подобные задачи. И со временем у вас появится понимание, сколько может занять та или иная новая задача, аналогичная тем, которые были сделаны раньше. И если вы видите, что оценки значительно расходятся, этому всегда должно быть понятное объяснение, почему аналогичная задача занимает больше или меньше времени. Попросите разработчика пояснить это. Также обычно последующая подобная задача занимает меньше времени, так как делается быстрее по аналогии.

Ну и если у вас возникают вопросы (например, почему скорость снижается) - всегда ведь можно просто спросить у разработчика - почему так получается? Есть ли какие-то проблемы с работой? Что может помочь вернуть скорость на прежние показатели?

Телепатия, к сожалению, пока только фантастика, и мысли читать никто не умеет. Поэтому единственный способ что-то выяснить - это общаться.

Answer 7

[Ilya Bobkov]

Никак, ждите, верьте, надейтесь. Кроме написания кода у человека есть ещё и другие задачи. Вы лучше опишите что за сервис и вам примерную оценку по времени дадут.

Comments

[mamkaololosha]

Какие? не работать ибо фрилансер?

[Ilya Bobkov]

mamkaololosha: это к психологу

[Максим Тимофеев]

Пишет явно фрилансер, который привык затягивать проекты.

[Ilya Bobkov]

Максим Тимофеев: Да не

Answer 8

[Егор Казанцев]

Желание контролировать происходит из суждения что все люди идиоты. Проблема в том что неИдиоты стоят дорого. Так же относительно программиста вы можете быть идиотом. Помогают короткие итерации, платите много и пускай программер "трахаете" вам мозг за ваши деньги ибо только вы знаете что вам надо. Вообще я за повременную оплату , но с мозготрахом, а не то что на тебе ТЗ и фигачь - а потом выясняется что нафиг это не работает , потому что разраб ТЗ не моделировал в своих мозгах даже примерно как оно будет.

Comments

[loxenehej]

Контроль - подстегивает исполнителя.
Ситуация - когда исполнитель говорит, что делает или думает, а при этом неделями не прикасается к коду - более чем распространенная. Сколько бы ему не платили.

Я сам такой - в заказе на 10 000 долларов за неделю могу вообще ничего не делать - ленюсь.

Answer 9

[Elesey]

Тут проблема действительно сложнее просто контроля. Но если речь про то, как контролировать, то можно использовать специализированные программы, позволяющие вести трекинг-задач и тогда вы получите полный спектр информации: сколько прогер тратит времени на те или иные задачи, где у него слабые и сильные стороны. Вот неплохой обзор по системам учета рабочего времени: https://software-audit.ru/

Comments

[AndreyKeer]

Мы решали похожую задачу. Интересно какой трекер выбрали в вашей компании?

[Elesey]

Мы выбирали между Bitcop и Crocotime. И остановили свой выбор на перовой системе, так как требовалось сделать интеграцию с системой управления проектами Redmine и они предложили более доступное решение.

[AndreyKeer]

Знакомая ситуация :) Только мы интеграцию делали сами, у Bitcop открытый API и техническая поддержка помогла разобраться с настройкой. Как у вас в целом эффективность труда повысилась?

[Elesey]

:) Инструмент полезный для аналитики, но насколько эффективно это вопрос риторический. Разработчики люди творческие и очень сложно оценивать реализацию похожих задач на которые затрачивается больше времени.

Answer 10

[Timur Mikhaylov]

Все, что описано ниже потребует от Вас больше времени на контроль, общение и т.п.
1. Разбивайте задачи, что бы длительность была не более 4-х часов
2. Просите предварительную оценку каждой задачи в часах, и если будет сильно из нее вылезать в процессе просите что бы объяснял почему. Не платите если вылез за оценку без предупреждения
3. Подключите еще одного разработчика или нескольких, создайте конкуренцию, что бы они видели друг друга, пускай они оба оценивают одну и ту же задачу, а вы решайте кто будет делать
4. Давайте отрицательную обратную связь. Не выдержал сроки - получает первый раз предупреждение, потом штраф

p.s. А так же учтите советы Евгений и Максим Тимофеев

Answer 11

[loxenehej]

Это частая практика - он просто врет, а сам делает другие проект.

Даже если вы в коде не разбираетесь, то можно хотя бы глядеть на объемы написанного.
Или пригласить специалиста со стороны на аудит - это не дорого.

Answer 12

[Alexey Kamchatkin]

Есть отличные тайм-трекеры , причем некоторые логают все , запущение программы, делают скриншоты и все это шлется на сервис в котором вы как главный, Вы главный и поэтому Вы будете как - менеджер, продюссер и тим лидер, который должен уметь контролировать все эти вопросы. Плюс, когда вы думаете работать с удаленным программистом, то - надо понимать какими методами разработки вы будете следовать, далеко ходить не надо и взять к примеру, Agile. Ознакомьтесь с ним чтобы уяснить что Вам нужно от программиста и ему от Вас, здесь я больше указываю на так называемые - "стори". Также , знакомьтесь с портфолио программиста, проводите интервью с ним же, сделайте список вопросов перед этим. Ну и главное , у Вас должен быть хороший капитал. Ну и посоветую книжку прочесть - Идеальный программист. Есть вопросы пишите. отвечу.

Answer 13

[Hatsu]

Если смотреть на эту проблему со стороны разработчика, то такие заказчики часто не правильно оценивают понятие сложности. Порой на ту задачу которую заказчик считает "сложной" уходит пару часов, а то что "лёгкой", требует больших правок в проекте и долгого времени на обдумывание и внедрение. К тому же подобные заказчики хотят платить только за нововведения, такие понятия как рефакторинг они считают пустой тратой денег, а их хотелки часто даже не предусматривались в проекте, и из за этого нарушают общую концепцию и качество кода.

Comments

[loxenehej]

А если смотреть на это со стороны опытного разработчика и опытного заказчика, то то, что тебе вешают лапшу на уши, а при этом занимаются другими проектами - очень распространенная практика.

Обдумывание - это как минимум перестановка кода.
Если ничего не меняется - ничего и не делается и не обдумывается, а это просто лапша на уши.

[loxenehej]

Тот же рефакторинг - хорошо видно.

Переставлять куски кода ради иммитации бурной деяетельности - лениво нормальному спецу.

Answer 14

[Виталий Кузнецов]

Фронтенд тоже не видно, если что. Это верстку иногда видно))

Как контролировать — никак. В контроле нуждаются дебилы.

Но с дебилами лучше не работать.

Лучше выбирайте специалиста. Изучайте менеджмент по программированию.

А так можете по коммитам отслеживать.

Ну вообще проблема на двух сторонах. Так себе программист. Так себе заказчик.

Будь у меня такая проблема — я бы начал с себя.

Comments

[yan_pnz]

Когда идете к врачу, вы изучаете медицину и анатомию, чтобы быть правильным пациентом?

Или просто хотите избавится от боли/болезни, не вникая в медицинские аспекты лечения и химические составы лекарств?