Как эффективно работать с программистом?

Question

[The Whiz]

Друзья, дайте советов новичку в этом деле.

Я человек с довольно большим багажом знаний, кроме непосредственно серверного программирования. Большой опыт оффлайнового проэктного менеджмента, дизайн, UX, ну и мелочи вроде вордпресса (иногда фрилансю). В силу различных обстоятельств, я планирую начать работать над одним проектом средней сложности, для которого мне понадобится помощь веб-программиста, дел с которыми я раньше не имел. Сроки и качество исполнения для меня стоят на первом месте. Не хотелось бы, чтобы первый блин вышел комой. Помимо сложностей с выбором, собственно, человека (вон сколько фрилансеров, выбирать их по чистоте кода или по послужному списку?) — хочется понимать, как контролировать сам процесс. Asana? Мегаплан? Заводить ли багтрекер? Что-то еще? Как грамотно выставить дэдлайн? Я понимаю, что тема бесконечная, но хоть какой-либо чужой опыт мне очень сильно помог бы.

Возможно, у кого-то есть отработанная схема работы с бэкэндщиками на фрилансе?
Прошу совета у сообщества.

Answer 1

[Руслан Лопатин]

Программист — это исполнитель прежде всего. В этой роли его и используйте. А нагружая его «дедлайнами» и прочей управленческой чепухой вы заставляете его делать несвойственную ему работу, фактически перекладывая на него свою ответственность.

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

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

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

Answer 2

[pomeo]

asana, мегаплан и т.д. это всё фигня для работы с одним человеком. Он назовёт срок, умножайте его на три(скорей всего вы и сами это знаете). Если он уложится в то что назвал, держитесь его и никогда не теряйте =) То что он пишет вы должны это видеть, пусть он коммитит на github либо ещё куда, коммиты должны быть каждый день.

Answer 3

[arezvov]

Система управления нужна, даже если сам и менеджер и программист в одном лице.
Но хватит простейшей. Успешно использовали Trac (http://trac.edgewall.org/) в команде в 5 человек.
Можно заняться самостоятельной установкой и обслуживанием (не сложнее апача настроить), а можно использовать готовые Trac-хостинги.
Удобство — интеграция системы управления с системой контроля версий.

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

Но все это — лишь инструменты, чтобы ими пользоваться надо наладить процесс управления. Определенно нужны правила, хотя бы на листке А4, как сказано выше ежедневный коммит — хороший кандидат для этих правил.

В своих удаленных проектах я использовал элементы скрама — планирование, митинги, демонстрации. Полнота реализации зависит от ваших возможностей и потребностей.
Например:
1. Собираемся в 20 февраля на планирование, я определяю дату сдачи спринта, давайте возьмем неделю в качестве тренировки, потом сможете увеличить продолжительность, по мере роста доверия к оценкам. Определяем количество сторипоинтов в спринте исходя из ваших договоренностей с исполнителем о том, какое время он будет уделять работе. Возьмите поправку для себя, аналог фокус-фактора (мое личное предпочтение — не обсуждать фф с удаленными исполнителями, потому и аналог), поправка для профессионала в слаженной команде — 0,7 — 0,8, для профи в новой предметной области — около 0,5. В процессе работы уточните. К примеру насчитываем 20 часов, с учетом фф 0.5 = 10 ч/ч. Устанавливаем дату сдачи спринта 27 февраля (заметьте, еще до того как определили, что именно делать).
2. Исполнитель оценивает задачи в часах, в реальных в отличие от скрам. Исходя из приоритетов и учитывая целостность результата по окончании вы набираете задачи на спринт, можете зафиксировать их в версии или milestone в trac.
3. Ежедневно (или с другой периодичностью, но лучше ежедневно) в установленное время собираетесь на митинг 5-15 минут, исполнитель проговариает три вещи: что сделал вчера, что делает сегодня, с какими затруднениями столкнулся. Это самое важное мероприятие из всех, стимулирует к работе, позволяет заранее вскрыть проблемы. На этом мероприятии обычно задачи передаются в тестирование, но если тестировщика нет, вероятно замените его вы, в таком случае вы принимаете выполненные задачи и на следующий день на митинге отчитываетесь об успешной их проверке или возвращаете их исполнителю.
4. 27 февраля собираемся на демонстрацию, позвольте самому исполнителю отчитаться о проделанной работе (показать реализованный функционал по пунктам), вероятно он расскажет о недоработках, идеях, проблемах, где-то вскроется неправильно реализованная логика. (В случае, когда вы сам тестировщик — пункт спорный, но некоторое мероприятие на сдаче, хоть и короткое я рекомендовал бы проводить).

Важно, что система управления (методика+интсрументы) должна помогать решать ваши задачи, если нечто мешает кому-нибудь из участников, при этом никому не помогая — устраняйте или модифицируйте это нечто.

Answer 4

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

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

Comments

[The Whiz]

Как вы оцениваете что задача на 8 часов? Мне как непрофессионалу в программировании это сделать достаточно тяжело. А если проект пишется с нуля?

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

Опыт и мнение других программистов, как то я был программистом и сисадмином, и представляю что такое юи и алгоритмы, и могу прикинуть сколько и что писать.
Задачи разбиваю как можно мельче так их проще оценить.
Если сами не можете, бьете проект на подзадачи, идеальный квант при нескольких программистов около 2-4 часов на задачу, даете нескольким программистам на оценку, ну смотрите где примерно одинаково то там ок, где большие расхождения спрашиваете у того кто загнул планку с чем это связано.
Очень тут в оценке хороша методика из скрама, когда собираются программисты в кружок, у каждого карты от 1 до 10 и одна карта вопрос. Скрам мастер рассказывает про задачу потом все ложат карты числом вниз вскрываются, если все положили скажем двойки и тройки, в таск менеджере пишется, что для задачи надо 2-3 часа, если кто то выложил к двойкам и тройкам 10-ку, то у него спрашивают в чем дело то, тут либо у него недостаток опыта, либо наоборот он видит подводный камень, если подводный камень то голосуют заново. Если человек ничего не понимает в задаче то он кидает карту с?

Answer 5

[Дмитрий Белоглазов]

ТЗ + Система управления проектами (PM, мы используем feng office) + система контроля версий (SVN).
На первом этапе составляется ТЗ с планом работ и детализацией.

ПП: разработка модуля обработки испытания:
1. Адаптация модели данных: 4 часа,
2. Выборка из протокола данных: 2 типа протоколов по 2 часа на каждый + 1 час на отладку = 5 часов,
3. Разработка GUI: 3 контрола с графической обработкой * 4 часа на каждый + 2 контрола для таблиц * 1 час на контрол + 1 контрол общей информации * 0.5 часа = 14.5 часов
4. Тестирование GUI: 3 графической обработки * 0.5 часа = 1.5 часа
5. Разработка отчета: дизайн 16 часов + верстка 8 часов + отладка 16 часов = 40 часов
Итого: 60 часов

Составляем ТЗ на весь проект, добавляем от 50% до 200% запаса по времени. В дальнейшем ТЗ будет пересматриваться, работы будут переставляться, сроки сдвигать в меньшую или большую сторону, но фактически разработка займет рассчитанное время с небольшим отклонением. Правда на составление такого ТЗ уходит довольно много времени.

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

При разработке вдвоем показала себя хорошей практика 1-го коммита в 1-4 часа в ветку и каждые 4-7 часов слияние веток. Большие изменения не накапливаются и оба работаем над актуальной версией. Для своих личных проектов стараюсь придерживаться такого же ритма. Главным преимуществом при разработке в одиночку является возможность быстрого отката последних изменений, да и затраты времени считать удобно.

Максимально допустимым сроком комита является 8 часов (1 рабочий день). Если интервал коммитов превышает этот срок, то возможны только 3 варианта: 1. Работа стоит, 2. Возникла серьезная проблема, 3. Задача слишком большая и нужно было ее более подробно детализировать. Если возникает именно 3-й случай, то нужно проверить ТЗ на похожие задачи и детализировать их. Так же коммит должен идти на каждое исправление бага, с обязательным оповещением остальных о необходимости срочно получить свежую версию.

Минимум 1 раз в неделю детальное обсуждение состояния проекта всем отделом(компанией, группой, нужное подчеркнуть), желательно с чек-листами проверки работы программы. Так же 1 раз в месяц можно требовать отчет о проделанной работе в письменном виде, возможно с пакетом документации на программу. Главное не забудьте внести в ТЗ минимум 4 часа в месяц на него (если с документацией, то минимум 8-16).

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

PSS. Удачи!

Comments

[The Whiz]

Спасибо за развернутый ответ
Это будет очень интересно!

Answer 6

[gleb_kudr]

Система контроля версий и отсмотр коммитов. Важна регулярность. Ничего работающего кроме этого пока не нашел. Задачи удобно вести в багтрекере, разбивая их на атомарные единицы. Доразбивать нужно в процессе работы (все сразу не получится).