Begin /* Распределенная разработка
Тема, наверное, не совсем относящаяся к начинающим разработчикам, скорее к начинающим управленцам. Однако, есть мнение, что управление проектами разработки программного обеспечения получается лучше все-таки у тех, кто прочувствовал нюансы разработки что называется на собственной шкуре. Не все согласны с таким мнением. Многие не без оснований считают, что управление командами разработки это всё-таки несколько другая наука, больше связанная с социальной и экономической, чем с инженерной. С другой стороны, кибернетика - наука об управлении - сама по себе является достаточно точной математической дисциплиной, нежели чем гуманитарной. Так или иначе, от того, что организацией программистов занимается человек с программистским прошлым, а не чистый менеджер, хуже никому не становилось.
Лично мне потребовалось немного вникнуть в эту тему не по причине того что приходится кем-то управлять, а из-за того что не устраивает то как управляют мной. А раз не нравится - надо предложить. Ну а раз уж предлагать, то что-нибудь хотя бы не хуже того что есть. Следовательно надо понять, что и как устроено на данный момент, откуда растут ноги, какие есть альтернативы и что в итоге из всего этого должно следовать. А перед этим, нужно, как водится, дать определение.
Распределенная разработка ПО
В связи с повсеместным внедрением гибких (agile) методик разработки и, в последнее время, ростом популярности удаленной работы, возникла необходимость в адекватном способе управления разнообразными командами и оценке трудозатрат и результатов работы. Не то что бы распределенная разработка не существовала ранее, но, как правило, раньше она была связана с некоммерческими проектами. Где не сильно важно было оценивать экономический выхлоп от деятельности того или иного сообщества разработчиков. Примером разнообразные фонды открытого/свободного ПО.
Сейчас же архиважно стало перенести модели оценки экономических показателей, существовавших в рамках классических офлайн команд на рельсы удаленной работы. Как проконтролировать работника? Как его мотивировать? Какую зарплату начислить? В конце-концов как оценить компетенции соискателя не приглашая его на личную беседу? Все эти вопросы теперь волнуют не только службу персонала и бухгалтерию, но и непосредственно владельцев проектов, подрядчиков и прочих участников процесса, отвечающих за деньги, время и, что немаловажно, качество продукции.
В условиях, когда невозможно проконтролировать время затраченное работником на решение той или иной задачи, когда не известна даже исходная квалификация исполнителя банально очень трудно, а чаще всего и невозможно, распределить вознаграждение по заслугам. Сложно это делать и даже когда известно, что человек стучит по клавиатуре 8 часов в день, а в послужном списке конкретные достижения. Ну а если вы никогда не видели человека, условия труда, его диплом, а может быть даже не знаете номера телефона, то рассуждать о вкладе участника в общее дело, а уж тем более прогнозировать выхлоп от такой черной лошадки, занятие такое себе. Письмо вилами по воде покажется не таким уж бесполезным занятием.
Наивно было бы предполагать, что попытки формализовать эти процессы не предпринимались или предпринимались только в каких-то ограниченных условиях и закрытых корпоративных ноу-хау. Тот же аджайл, собственно, частично решает часть проблем. Спринты, девопсы, канбаны относительно легко переносятся на удаленную работу, но при условии, что формируются команды все-таки как-то в одном исходном месте с единым пониманием процессов. Есть и универсальные научные подходы. Применимые, однако, в очень ограниченном спектре задач.
Научный подход
Исписаны тонны материалов о том, как правильно следует оценивать сложность той или иной задачи. Даже не строго программистской, а вообще подразумевающей любое алгоритмическое решение проблемы. Так, например, существует способ COSMIC, основанный стандартизированных подходах оценки функционалов в неких условных баллах. Провозглашается, что метод достаточно абстрактен для любых типов задач. Имеет экономическое и математическое обоснование.
Казалось бы, бери и пользуйся - умные люди давным давно обо всем позаботились. Однако же, сама методика оценки программ в функциональных баллах (function points) была предложена аж в 1979 году неким Аланом Альбрехтом для целей компании IBM и не видно, что бы она сильно была бы распространена среди других организаций. Что-то подсказывает мне, что и в IBM нынче не сильно ею пользуются.
Проблема наверное в чрезмерной универсальности и, скажем так, наукоемкости. Что бы такой системой пользоваться с надлежащей эффективностью надо в ней во-первых хорошо разбираться. Что, например, лично мне показалось тяжеловато. А поскольку я, может быть самонадеянно, считаю себя не сильно глупее своих коллег, то и коллегам с ходу такую систему применить в простых повседневных задачах будет сложновато.
Похожими проблемами страдают и другие научные подходы. Они не очевидны, не интуитивны, требуют изначальной подготовки. Это как-раз, наверное, для тех профессиональных управленцев, которым с такими вещами работать положено. Тем не менее на практике не видно что бы и профессиональные управленцы спускали нам какие-то хитроумные методики оценки, такие что бы и волки целы и овцы сыты. Зачастую управленческие решения как-раз таки выглядят топорно и вульгарно. "А давайте вот не будем ничего выдумывать и по-дедовски считать человеко-часы."
Метод в лоб
Прямой перенос методик предназначенных для стационарных офисов на удаленную работу в отличии от научного подхода применяется управленцами куда охотнее и чаще. Не знаю с чем это связано. С низкой квалификацией этих самых управленцев, с инертностью руководства, с банальной ленью? Тем не менее существуют целые комплексы костылей реализующих те или иные формы управления сотрудниками удаленно. Это и разнообразные способы фиксации времени "активности" удаленного пользователя в закрытой сети, это и всяческие количественные оценки типа число строк кода, коммитов, закрытых задач за период времени. Доходит до буквального видеонаблюдения и журналирования нажатий клавиатуры.
Это безусловно уход в другую крайность. Если применить все эти костыли разом, возможно, вы и сможете заставить сотрудника действительно усиленно стучать по клавишам с девяти утра до шести вечера, но толку от этого будет не намного больше чем такой же стиль управления в очной форме. Это всё в итоге рано или поздно плавно перейдет в "гонку вооружений" между желанием работодателя максимально выжать из сотрудника все соки, и такой же силы желанием обойти все эти средства контроля с целью получить больше денег за минимальное количество фактического труда. Я вот уже третий час увлеченно стучу по клавиатуре и читаю вроде бы умные статьи. Кто возьмется определить нужно ли то чем я занимаюсь в данный момент для выполнения какой-то оплачиваемой полезной работы? Сильно сомневаюсь, что такой человек вообще существует. А если и существует, то их придется посадить над каждым сотрудником. Ну и немедленно возникнет вопрос, а выполняют ли контролеры свои обязанности достаточно добросовестно?
В общем идея прямого переноса тотального контроля мертва изначально. Что и было неоднократно, в том числе и лично мной, доказано на практике. Во-первых потому что она не работает и очно, во-вторых время затрачиваемое на изобретение костылей куда проще потратить на научный подход. Что, надо сказать, многие работодатели всё-таки понимают, если не сразу, то в результате горького опыта. А сводится это понимание часто к третьему, промежуточному варианту. Ну, а именно к нашим с вами проевшим плешь "стори поинтам" (story points).
Что не так со стори поинтами?
Со стори поинтами всё хорошо (спойлер). Просто есть те (опять же управленцы), кто превратно их трактует. И тем самым выедает эту самую плешь у сотрудников. Во-первых, это конечно же пресловутая привязка всё к тем же человеко-часам, трудо-дням, строкам кода и всему что категорически не нравится самим разработчикам. Во-вторых, и в исходной методике выставления этих самых стори поинтов всё-таки не всё так гладко, даже когда они трактуются по всем канонам аджайл.
Существует дюжина способов и нюансов связанных с этим процессом. Каждый имеет свои плюсы и минусы. Где-то надо изначально убить время на избыточный предварительный анализ, когда, например, усредняется мнение всех заинтересованных. Где-то необходимы частые очные совещания и ретроспективы, что естественно затруднено в удаленном режиме. Где-то просто нет такого потока задач и количество команд для адекватного сведения и анализа результатов применения.
В среднем, методика худо-бедно работает. Классический вариант относительной оценки при хорошо отлаженном процессе это именно то решение, на котором в итоге останавливается большинство серьезных и не очень организаций. Однако существует и более глубокая проблема с каноническими стори поинтами. Они плохо мотивируют. Поясню.
В классическом варианте все-равно требуется высшее управляющее звено - менеджер проекта, владелец, заказчик, который так или иначе вынужден приближенно декомпозировать задачи, формулировать их, приоритизировать, устанавливать дедлайны, мотивировать. Далее это же звено должно собирать итоги в кучу, производить какие-то манипуляции с вознаграждением, принимать кадровые решения.
Это обстоятельство в общем не мешает применять методику удаленно и сотрудники здесь как бы не обязаны физически присутствовать, но тем не менее это всё-равно некая централизация - привязка к определенному руководству. Более того не очень понятно, как рассчитывать вклад в общее дело других участников, таких как аналитики, тестировщики, дизайнеры и прочие товарищи на напрямую не решающие эти самые задачи.
Может быть есть способ построить управление таким образом, что бы и заказчики, и менеджеры, и аналитики, и контроль качества - все находились внутри этого процесса, а не снаружи. Мне кажется что-то подобное возможно.
Стори поинты, являются по сути дальнейшей абстракцией точно тех же научных функциональных баллов, только более интуитивно понятных и простых в использовании. От тех же баллов, очевидно, происходит и привязка стори пойнтов к некой объективной "сложности" конкретного функционала.
Но что, если и дальше абстрагировать понятие и перейти на уровень выше? Что если стори пойнтами обозначать не только функциональную сложность, а включить в них вообще все трудозатраты всех участников процесса? Не только менеджеров, аналитиков, тестировщиков но и, возможно, переводчиков, технических писателей, администраторов, водителей, уборщиц, да кого угодно.
Почему мы должны оценивать работу одних как-то современно и модно, а других в старомодных явках, прогулах и пробегах? Может вообще надо отказаться от понятия "сложности"? Может важнее "востребованность", "целесообразность", "польза"? Или даже какая-нибудь "топовость"? "Топовая" фича должна иметь дополнительные баллы независимо от сложности реализации. Может быть экономические критерии должны проистекать наоборот из готовности работать над задачей? Может быть не надо рассматривать участников как носителей каких-то скилов и компетенций? Предоставил человек свой труд на решение задачи, совершенно не важно как и какой, не важно сколько для этого понадобилось ему личных ресурсов - получит он ровно столько, сколько набрал он этих стори пойнтов.
В общем
Крутится в голове что-то радикальное, глобальное. Но выхода пока не находит. Модель оценки вознаграждения по вкладу в общее дело мне кажется наиболее естественная и мотивирующая - справедливая что ли. Важно сделать так, что бы она была одинаково справедлива для любого участника, с какой угодно квалификацией.
Не может человек выполнить задачу сразу на сотню баллов - пусть делает десять по десять. Может аналитик разбить задачу на сотню на десять по десять - пожалуйста, но при этом, скажем, оставит себе десять от общего. То есть изначально человек который сделает девять по десять получит меньше, чем тот кто умеет сразу за сто. Аналитик может работать с несколькими задачами сразу.
Контроль качества, допустим при этом может вычесть из выполненных ста по пять за каждый обнаруженный недочет. Накосячил разработчик - потерял половину. Нарыл тестировщик багу - вложился в общее дело - получил соответствующее вознаграждение. Если менеджеру проекта удалось получить от заказчика исчерпывающую спецификацию, которую потом легче декомпозировать - получил процент от аналитиков. Как-то так.
А может быть даже заказчик сам разбил свой проект на подпроекты - сэкономил на лишнем менеджере или аналитике. Возможен и личный обмен: обучил техлид джуна решать более сложные задачи быстрее - джун отблагодарил своими баллами.
Система сложная, но в то же время копирует модель поведения обыкновенных человеческих отношений. А поэтому, я искренне убежден, может быть применена на практике. Возможно, она уже где-то успешно применяется, возможно интуитивно, возможно формально. Мне отыскать пока не удалось. Буду искать дальше, а то что найду обязательно выложу. Так что кому интересно, следите за обновлениями рубрики.