Здравствуйте, Yodo, Вы писали:
Y>У кого есть опыт?
Ну а кто ж тебе готовое решение скажет без знания всех деталей? Если с человеком регулярно общаетесь, всё решается прямым вопросом-ответом, если доверия нет, начинается нудятина. Я бы предпочёл поговорить лицом к лицу, в крайнем случае по телефону. Повестка стандартная — узнаём про проблемы, в зависимости от ситуации предлагаем варианты (вы всё уже написали выше): меняем схему работы, разработчик мотивирует себя сам, временно работает на полставки, уходит на больничный, увольняется. Даём время подумать, закрепляем решение.
Судя по тому что Вы написали, мне кажется что у Вашего сотрудника (programmer's burnout) выгорание, но к счастью это обратимый процесс.. Мне кажется тут поможет только "выгнать" этого программиста в оплачиваемый (!) отпуск недели на 3, а лучше на месяц, причем с обязательным (!) условием показать Вам по WEB-камере или на фотографии с ним купленный билет на самолет на юга. Просиживание отпуска дома, или поездка к знакомым в другой город не поможет никак. Поездка с женой, а лучше одному чтобы хорошо "оторваться" там. — это 1-ое и IMHO самое главное действие в такой ситуации, а 2-ое: обязать его всё-таки иногда приезжать в офис и отрабатывать там целый день.. если Вы работаете с ним в одном городе — то можно выбрать какой-нибудь день недели — чтобы он раз в неделю приезжал в офис и общался с вами и остальной командой, если живет далеко — то хотя бы раз в месяц или в 2-3 месяца чтобы приезжал на 3-4 дня, если есть возможность оплатите ему дорогу и проживание на эти несколько дней, или например оплатите 50% расходов на это, но сделайте это обязательной процедурой, такие поездки будут очень его бодрить (в хорошем смысле слова).
Я сам был в такой ситуации (как у вашего сотрудника), правда работал в офисе, но остальная часть команды была в другом городе, т.е. фактически удаленно.
Уволить человека Вы конечно всегда сможете, но мне кажется в данной ситуации, раз он давно с вами работает, эффективней будет помочь ему это преодолеть этими двумя шагами (возможно он сам даже не замечает к какому состоянию пришел), думаю после хорошего длительного отпуска производительность его станет той же как раньше или даже выше..
Здравствуйте, Yodo, Вы писали:
Y>- вещи, которые год назад делались за несколько часов, сейчас требуют пары дней Y>- задачи выполняются невнимательно, из-за этого вылезают баги и переделки
Так, анамнез собрали. Теперь надо переходить к анализам, потому что симптомы могут соотвествовать куче различных причин. Про "баги и переделки" хотелось бы услышать подробнее. Они могут выглядеть по-разному:
1. Было забыто то, что явно упоминалось в письме.
2. Было не сделано то, что подразумевалось или что-то не совсем так работает.
3. В результате отвалилось что-то, не связанное с исходной задачей.
В результате анализа ошибок можно уже строить гипотезы, уточнять их и потом действовать по обстоятельствам. Группы далее примерно соответствуют категориям выше.
Первая группа — это невнимательность. Может вызываться различными причинами. Начиная от снижением мотивации и заканчивая банальной усталостью. Решения — от смены сотрудника до предоставления ему обязательного оплачиваемого отпуска.
Вторая группа — коммуникационные проблемы (с обеих сторон). В течение года у вас выработался некоторый язык и появились "умолчания". Проблема только в том, что умолчания сейчас воспринимаются по-разному с вашей стороны и со стороны разработчика. В результате получается не то, что вы хотели. Не потому, что программист потерял мотивацию. А потому, что задачи стали менее детальными (больше умолчаний). Решается признанием проблемы и настройкой коммуникации. В качестве первого шага можно попробовать давать более подробные задания. Можно описать ситуацию разработчику и попросить обратную связь от него. Смена разработчика может улучшить ситуацию. Но не из-за мотивации, а в силу процесса начальной "притирки" друг к другу, когда умолчаний в общении будет меньше. Зато новый разработчик ваш проект не знает. Так что я бы порекомендовал сначала общаться с тем, кто есть.
Что интересно, вторая группа может быть связана как с первой, так и с третьей. Например, при накопленной усталости все умолчания и неявные требования воспринимаются хуже или просто не замечаются. А может быть, в процессе написания детальных требований вы обнаружите, что не все так просто и имеется в наличии третья группа проблем.
Третья группа — проект достиг критической массы. Добавлять новую фичу в проект с тремя функциями и с двумя десятками разных функций — огромная разница. В первом случае это гораздо проще. Во втором случае нужно следить за тем, чтобы все работало как прежде. Еще и требования желательно подогнать под остальные функции. Вот строите вы дом. Пока есть один-два этажа, там все можно поменять. Когда есть уже 15 этажей, переделки будут медленнее. "Поставить эскалаторы в добавок к лифтам" проще делать в маленьком доме. Видите разницу? Т.е. замедление может быть вызвано самим усложнением проекта (essential complexity). А также оно может быть вызвано ухудшающимся качеством кода (спагетти и прочие ужасы технического долга). Причем долг может быть как осознаваемый программистом, так и не осознаваемый им, что дает совершенно разную картину. Плюс долг снижает мотивацию, это тоже нужно учитывать. Год — вполне достаточный промежуток, чтобы начали проявляться подобные эффекты сложности проекта/кода.
В третьей группе действия и прогнозы будут разными.
Essential complexity можно легко найти. Попробуйте писать более подробные требования. Вы сразу (ну не сразу, а по результатам анализа упущений в требованиях) заметите связность различных фич и сложность проекта. Можно просто смириться или попробовать упростить требования. Точнее, перегруппировать их и сделать менее связными (заодно и пользователям приложения может стать лучше). На требования разработчик мало влиять может. Так что применять к нему какие-нибудь меры (кроме просьбы помочь разобраться в ситуации) смысла нет.
Осознанный технический долг. Прогноз положительный, но тоже нужно общаться. Поговорите с программистом. Изложите свои проблемы. Может быть, он уже давно хочет что-то изменить/переписать. Сделаете оплачиваемый рефакторинг/реинжиниринг вместо нескольких фич. Вернете скорость и мотивацию повысите.
Неосознанный технический долг. Здесь прогноз уже далеко не такой положительный, так как реальной проблемы и пути исправления никто не видит. Можно как-то попробовать мотивировать разработчика искать более глубинные проблемы. Но вы должны понимать, что в случае успеха вы пройдете "осознанный технический долг", после чего производительность программиста повысится (он теперь имеет более широкий кругозор) и вам придется поднять ему зарплату или предоставить больше свободного времени. Можно попробовать получить консультацию других разработчиков. Или нанять кого-нибудь другого (можно в параллель, чтобы обучить вашего). И готовьтесь к тому, что вам в итоге предложат все переписать. Ну или последовательно отрефакторить от 10 до 80% приложения. Запущенный технический долг — он такой. Обычно вызван недостатком квалификации на момент написания кода, так что метастазы можно найти по всему приложению.
Итого.
Как видите, в большинстве вариантов лучший путь — прямой диалог. Только сначала нужно более детальную статистику собрать по типам проблем. Мотивации может дать временный эффект, но в большинстве случаев картину радикально не изменит, да и правильный метод выбрать сложно. Смена сотрудника может помочь в отдельных случаях (либо первая группа, либо неосознанный долг из третьей), но при этом работают все стандартные риски смены сотрудников.
Так что анализируйте проблему глубже. Ну и общайтесь, конечно.
Здравствуйте, Yodo, Вы писали:
Y>Но последнее время(несколько месяцев) стал выдавать результаты меньше, по ощущениям около 60% от нормы.
По ощущениям? По ощущениям некоторых директоров заводов прибыль приносит лишь финансовый отдел, а производственный одни убытки. По ощущениям металл холоднее пластмассы, а пирометр нагло врёт. По ощущениям в больничном морге лежат несколько трупов, а в палатах множество больных с температурой, но в среднем все здоровы. Прежде чем говорить о 60% нужно понять, что такое норма. Даёшь три программистских нормы за смену, родина мать зовёт.
Y>ЗП по рынку.
Огласите всю сумму. Если в регионе человек согласился работать за 20 тысяч рублей, а в Москве его работа стоит 120 тысяч рублей, то дело не в рынке. А если в США он к примеру на том же самом сможет заработать 10 тысяч долларов. Если норма это то, что выдавал человек раньше, опять же по ощущениям, от самого себя, то это не норма. Есть ещё такое понятие как "технический долг", чем дольше говнокодишь, тем больше долг, тем меньше будущая производительность.
Что лучше, 10 условных единиц функциональности говнокода или одна хорошо продуманного кода? А кому как. Было интервью с директором 1C, там были высказаны многие интересные мысли. Например, проще продвигать одну марку — 1C, даже если внутри там совершенно разные никак не связанные продукты. Или что различные команды могут написать программу по одному ТЗ, но это будут разные программы. Заменяя одного человека другим получаем итог, но он не идентичен результату другого человека.
Y>— жестко поговорить (типа давай договоримся и определим график присутствия, штрафы)
Y>— мягко поговорить (типа я думаю что результаты стали хуже. давай разбиремся есть ли проблема, привести в цифрах его ухудшения, дальше по ситуации).
Y>— искать замену (человек выгорел?)
Y>— оставить как есть и пытаться как-то оздоровлять ситуацию, чаще общаться, интересоваться, контрллировать выполненную работу.
То есть удалёнщик до этого всё делал сам? Никто с ним не общался, не интересовался, просто получали выполненную работу и всё? Значит, хороший удалёнщик, надо брать. Когда человек управляет сам собой он становится руководителем. Мне вообще думается многие лезут не в своё дело пытаясь нанимать программистов.
Здравствуйте, dimgel, Вы писали:
V>>Мне вообще думается многие лезут не в своё дело пытаясь нанимать программистов. D>Вот эту мысль недопонял, разверните пожалста.
Предположим у некоего человека достаточно денег, то есть в принципе он уже может нанять каких-либо программистов. Естественно он не меценат и за это ему нужно исполнение некой хотелки. Даже бывшие или практикующие программисты могут не представлять всю сложность разработки программного обеспечения, а уж люди далёкие от разработки тем более.
Для понимания используют различные приёмы, тот же метод аналогий. Взять строителя, что бы он мог подумать о программистах. Разработчики это рабочие, а руководит ими прораб, то есть тим-лид. Если у него чуть более богатая фантазия, то он может вспомнить, что ещё нужен архитектор, а программа это здание. Мышление аналогиями привлекательно, так как объясняет незнакомые вещи знакомым языком, но к сожалению это самообман.
На самом деле строитель бы до этого не додумался. Он бы скорее ограничился моделью построения здания с помощью низшего рабочего звена. Есть некий человек, который делает всё, заливает бетон, выкладывает стены, коммуникации, водопровод, электричество, перекрытия, ставит окна, крышу, в конце идёт люксовая отделка, и всё это должно быть точно таким, как по ходу дела возникнет в голове у заказчика, но сумма фиксируется сразу, рабочему платят по рынку.
А чертежи и планы вообще не нужны, заказчик с гордо поднятым носом заявляет, что он платит за дом, а не всякие бумажки. Если же супер рабочий будет филонить, то не беда, в строительном бизнесе вместо одного каменщика, нанимаешь другого, и так во всём. Только строитель может подзабыть, что у супер рабочего нет чертежей, а здание у него как из фильма Тёмный город, постоянно трансформируется на ходу по желанию владельца.
Суть в том, что бизнес не связанный с созданием программных продуктов, но кому понадобилось индивидуальное решение пытается нанять программистов, которым можно полностью делегировать полномочия по управлению проектом. Но те, кому по-настоящему можно передать полномочия, могут открыть свою фирму и работать по дорогим контрактам, нежели за зарплату обычного кодера.
К тому же все на чём-то учатся, и пока это происходит кто-нибудь непременно терпит убытки. Потому обученный человек и стоит дорого, что он сразу работает и не приносит убытков из-за обучения. Мне, например, нельзя доверять управление программистами, то есть можно, но пока я обучаюсь у любой фирмы пойдут убытки. Если бы у меня был руководитель и он спросил, сколько осталось до того, чтобы сделать это и это, то для меня он бы расписался в собственной некомпетентности, так как это явная попытка делегировать мне его полномочия.
Вернутся к той же теме. Если бизнес не компетентен, а в данном случае всё выглядит именно так, то у него остаётся всего лишь один надёжный критерий. Или он готов платить текущую зарплату за текущую работу, или не готов. Без всяких там норм выработки и прочей бодяги. У американцев же есть поговорка, делай или плати. Или надо делать самому и качественно, или платить и смотреть на результат. А розовые мечты, что можно уволить и нанять фрилансера с 300% некой нормы, всего лишь мечты.
Может так и получится, а может будет один процент от нормы, с последующим сливом работодателя и так по цепочке от фрилансера к фрилансеру. Говорить с человеком о проекте я считаю в любом случае надо. Составлять требования, прояснять непонятные моменты. Жёсткие и мягкие угрозы, в том числе увольнение, это уже на любителя. Работал с человеком, всё устраивало, хотя может быть хотелось бы лучше. Потом на форуме какой-нибудь Вася Пупкин из девятого бэ класса посоветовал уволить фрилансера и его тут же уволили. Это смешно.
Здравствуйте, Yodo, Вы писали:
Y>В конце концов если ты такой умный и тебя не устраивает ЗП — нужно просто об этом сказать. Никто же не мешает искать работу в США и работать там удаленно. Да?
Да, потому если не нравятся услуги фрилансера, точно так же можно ему об этом сказать. Это его скорее демотивирует, но зато, когда вы расстанетесь, платить ему уже будет не нужно.
Y>Про самоорганизованность. А накой вообще нужен программист, который не может самоорганизоваться, тем более удаленщик? Пусть в дворники идет или на завод рабочим, где его начальник организует.
Лучший выход пойти на "завод по производству программ", там и зарплаты высокие и организуют люди у которых зарплата ещё выше. На российский завод главным результатом труда которого являются не программные продукты, ни рабочим, ни программистом, лично я, идти не рекомендую.
Y>Про управление. Я вообще не считаю что должен кем-то управлять. Есть технические задачи, есть деньги. Задачи надо выполнять. Программист удаленщик должен найти в себе мотивацию и самоорганизованность чтобы выполнять эти задачи за оговоренные деньги. Мое дело их проверять и принимать. Если нет — досвидания.
Если результат труда не устраивает, расставайтесь, да и всё. Сейчас это в моде. Главное не забывайте, что мотивированный дурак не сможет заменить даже одного не мотивированного специалиста. Мотивация не заменит компетентность. Вообще, под излишне сильную мотивацию при недостатке умений, очень хорошо говнокодить. Тема мотивации обширна, обычно рекомендуют подумать на тем, чем сотруднику может быть интересен проект, кроме денег. Но мотивация ладно, а вот самоорганизация это уже не какая-то там мотивация, она достигается лишь очень высокой квалификацией.
Y>Единственное что печалит в этой ситуации, что в мозгу у программиста хранится много информации по проекту и неть возможности ее передать без потерь другому. Собственно для себя буду решать — сколько денег и времени готов вложить в сохранение этой информации и его вовлеченности.
Это издержки отказа от управления. Можно создать артефакты системного анализа, но на это программист тоже должен тратить время и иметь более высокую квалификацию, чем просто кодер. Модифицируемость программного продукта важная характеристика. Впрочем может быть следующий фрилансер скажет, что ему проще всё заново переписать.
Здравствуйте, Yodo, Вы писали:
Y>Как правильно дать пинка мотивировать удаленщика?
Лично я обычно начинаю скучать и капризничать если очень долго (больше года) приходится быдлокодить в духе "быстрее гоним фичи, рефакторинги не нужны, пофиг что код говно и рассыпается". Варианта два: (1) дать мне время ублажить свою страсть к прекрасному — для общей же пользы, хочу подчеркнуть; (2) до свидания.
A>Может человек стал опытней, продумывает больше наперед? Часто бывает что не вникая в специфику проще выдавать результат. Когда уже понимаешь что к чему, то продумываешь более универсальное решение, которое проще в будущем дополнить/переделать
Я бы перефразировал:
Когда уже понимаешь что к чему, то перестаёшь придумывать более универсальное решение, которое и сложнее и никому никогда не потребуется, а делаешь то что реально проще в будущем дополнить
Здравствуйте, Yodo, Вы писали:
Y>Сейчас у него нет графика вообще. Когда хочет, тогда и работает. Человек свой график не выстраивает и работает, когда может (т.е. родители из района на другом конце города позвонили — попросили приехать кран починить, он поехал или собаку на прививку повез внутри дня) вроде все ок. Но последнее время(несколько месяцев) стал выдавать результаты меньше, по ощущениям около 60% от нормы. ЗП по рынку.
Может человек стал опытней, продумывает больше наперед? Часто бывает что не вникая в специфику проще выдавать результат. Когда уже понимаешь что к чему, то продумываешь более универсальное решение, которое проще в будущем дополнить/переделать
Несколько месяцев потери в производительности — это очень большой срок. Мой опыт говорит, что в 80% случаев что-либо делать бесполезно. Будет лишь краткосрочное улучшение на пару недель. С другой стороны есть другие 20%. Тут тебе решать. Поговорить в любом случае стоит, т.к. поможет тебе разобраться какие ошибки ты допустил на своей стороне, чтобы в следующий раз не наступить на те же самые грабли.
Здравствуйте, dimgel, Вы писали:
d> D>Молчание работника надо расценивать как "Надоело/есть что-то другое интереснее и/или прибыльнее" и переходить к поиску замены.
d> Необязательно. Может он просто необщительный, скрытный, стеснительный, или наоборот держит всех за козлов и считает, что долбить их бесполезно, и вообще, инициатива наказуема.
Если человек не может нормально работать только потому что ему не пообещали долю, проблема в нем.
Потому что уважающий себя специалист будет нарабатывать скилы, набирать опыт и повышать свою ценность именно как спеца. Соответственно постепенно получать бОльший доход.
Да, представь себе: работать нормально без доль, расти вместе с продуктом, который делаешь. Да, такие люди есть, да такие люди четко, слаженно и позитивно работают стремясь сделать продукт лучше. Если дела пошли в гору,
такой человек просто подходит и говорит "у нас все ок, не пора ли увеличить мои доходы", а я в свою очередь предлагаю увеличение ЗП заранее, как только есть такая возможность. Включи фантазию — такое бывает.
Здравствуйте, Yodo, Вы писали:
Y>Если человек не может нормально работать только потому что ему не пообещали долю, проблема в нем.
+1.
Y>Да, представь себе: работать нормально без доль, расти вместе с продуктом, который делаешь. Да, такие люди есть, да такие люди четко, слаженно и позитивно работают стремясь сделать продукт лучше. Если дела пошли в гору, Y>такой человек просто подходит и говорит "у нас все ок, не пора ли увеличить мои доходы", а я в свою очередь предлагаю увеличение ЗП заранее, как только есть такая возможность. Включи фантазию — такое бывает.
Да я как бы в курсе, что бывает. Но я сильно сомневаюсь, что такое может возникнуть само по себе, без усилий и понимания психологии со стороны руководителя. Т.е. руководители, у которых такое бывает, достаточно мудры сами по себе, чтобы спрашивать тривиальные и базовые для управленца вещи на форумах. И зарплату, кстати, не "предлагают увеличить", а тупо "увеличивают". Есть у меня, кстати, сомнения, что вы этим действительно сами хоть раз занимались просто от широты душевной, без намёков со стороны работников: кто способен сам принять решение о повышении зарплаты хорошему сотруднику, тот и решение об увольнении плохого примет без подсказок.
Вобщем ситуация такая: есть хороший разработчик на удаленке. Много времени проработал.
Сейчас у него нет графика вообще. Когда хочет, тогда и работает. Человек свой график не выстраивает и работает, когда может (т.е. родители из района на другом конце города позвонили — попросили приехать кран починить, он поехал или собаку на прививку повез внутри дня) вроде все ок. Но последнее время(несколько месяцев) стал выдавать результаты меньше, по ощущениям около 60% от нормы. ЗП по рынку.
С чем это может быть связано и как лучше воздействовать чтобы вернуть в нормальное русло?
Собственно варианты:
— жестко поговорить (типа давай договоримся и определим график присутствия, штрафы)
— мягко поговорить (типа я думаю что результаты стали хуже. давай разбиремся есть ли проблема, привести в цифрах его ухудшения, дальше по ситуации).
— искать замену (человек выгорел?)
— оставить как есть и пытаться как-то оздоровлять ситуацию, чаще общаться, интересоваться, контрллировать выполненную работу.
Здравствуйте, Yodo, Вы писали:
Y>Как правильно дать пинка мотивировать удаленщика?
Y>Вобщем ситуация такая: есть хороший разработчик на удаленке. Много времени проработал. Y>Сейчас у него нет графика вообще. Когда хочет, тогда и работает. Человек свой график не выстраивает и работает, когда может (т.е. родители из района на другом конце города позвонили — попросили приехать кран починить, он поехал или собаку на прививку повез внутри дня) вроде все ок. Но последнее время(несколько месяцев) стал выдавать результаты меньше, по ощущениям около 60% от нормы. ЗП по рынку.
Y>С чем это может быть связано и как лучше воздействовать чтобы вернуть в нормальное русло?
Y>Собственно варианты:
Y>- жестко поговорить (типа давай договоримся и определим график присутствия, штрафы) Y>- мягко поговорить (типа я думаю что результаты стали хуже. давай разбиремся есть ли проблема, привести в цифрах его ухудшения, дальше по ситуации). Y>- искать замену (человек выгорел?) Y>- оставить как есть и пытаться как-то оздоровлять ситуацию, чаще общаться, интересоваться, контрллировать выполненную работу.
Y>У кого есть опыт?
трекать время и задачи и смотреть на достоверность.
Здравствуйте, MaximVK, Вы писали:
MVK>Несколько месяцев потери в производительности — это очень большой срок.
Несколько месяцев?
Что-то я этот момент просмотрел у топикстартера. Тогда да, согласен с тобой и с SkyDance — поговорить всё равно не мешает, но на то, что что-то изменится, надеяться слегка поздновато.
Здравствуйте, Yodo, Вы писали:
Y>Как правильно дать пинка мотивировать удаленщика?
Y>Вобщем ситуация такая: есть хороший разработчик на удаленке. Много времени проработал. Y>Сейчас у него нет графика вообще. Когда хочет, тогда и работает. Человек свой график не выстраивает и работает, когда может (т.е. родители из района на другом конце города позвонили — попросили приехать кран починить, он поехал или собаку на прививку повез внутри дня) вроде все ок. Но последнее время(несколько месяцев) стал выдавать результаты меньше, по ощущениям около 60% от нормы. ЗП по рынку.
Y>С чем это может быть связано и как лучше воздействовать чтобы вернуть в нормальное русло?
Y>Собственно варианты:
Y>- жестко поговорить (типа давай договоримся и определим график присутствия, штрафы) Y>- мягко поговорить (типа я думаю что результаты стали хуже. давай разбиремся есть ли проблема, привести в цифрах его ухудшения, дальше по ситуации). Y>- искать замену (человек выгорел?) Y>- оставить как есть и пытаться как-то оздоровлять ситуацию, чаще общаться, интересоваться, контрллировать выполненную работу.
Y>У кого есть опыт?
Я бы в начале попробовал 2й вариант, потом 1. Если не прокатит — то 3й
Здравствуйте, DenisCh, Вы писали:
DC> Y>Собственно варианты:
DC> Y>- жестко поговорить (типа давай договоримся и определим график присутствия, штрафы) DC> Y>- мягко поговорить (типа я думаю что результаты стали хуже. давай разбиремся есть ли проблема, привести в цифрах его ухудшения, дальше по ситуации). DC> Y>- искать замену (человек выгорел?) DC> Y>- оставить как есть и пытаться как-то оздоровлять ситуацию, чаще общаться, интересоваться, контрллировать выполненную работу.
DC> Y>У кого есть опыт?
DC> Я бы в начале попробовал 2й вариант, потом 1. Если не прокатит — то 3й
Смысла в варианте 1 не вижу совсем, а уж тем более после 2.
Здравствуйте, dimgel, Вы писали:
d> Y>Как правильно дать пинка мотивировать удаленщика?
d> Лично я обычно начинаю скучать и капризничать если очень долго (больше года) приходится быдлокодить в духе "быстрее гоним фичи, рефакторинги не нужны, пофиг что код говно и рассыпается". Варианта два: (1) дать мне время ублажить свою страсть к прекрасному — для общей же пользы, хочу подчеркнуть; (2) до свидания.
Причина может быть и другая, поэтому надо разобраться из-за чего и после этого нейтрализовать неудовлетворенность тем или иным способом.
Здравствуйте, Dziman, Вы писали:
D>Причина может быть и другая, поэтому надо разобраться из-за чего и после этого нейтрализовать неудовлетворенность тем или иным способом.
Я своими "из-за чего" обычно открытым текстом долблю. Долго долблю, прежде чем устать. А если ТС-овый чел молчит как рыба об лёд — ну, разбирайтесь, чо.
Здравствуйте, dimgel, Вы писали:
d> D>Причина может быть и другая, поэтому надо разобраться из-за чего и после этого нейтрализовать неудовлетворенность тем или иным способом.
d> Я своими "из-за чего" обычно открытым текстом долблю. Долго долблю, прежде чем устать. А если ТС-овый чел молчит как рыба об лёд — ну, разбирайтесь, чо.
Молчание работника надо расценивать как "Надоело/есть что-то другое интереснее и/или прибыльнее" и переходить к поиску замены.
Здравствуйте, Dziman, Вы писали:
D>Молчание работника надо расценивать как "Надоело/есть что-то другое интереснее и/или прибыльнее" и переходить к поиску замены.
Необязательно. Может он просто необщительный, скрытный, стеснительный, или наоборот держит всех за козлов и считает, что долбить их бесполезно, и вообще, инициатива наказуема.
Здравствуйте, Yodo, Вы писали:
Y>С чем это может быть связано и как лучше воздействовать чтобы вернуть в нормальное русло?
Это связано с тем, что человеком никто не управляет, а работа — не трекается и не нормируется. Рецепт тут простой: планирование работы на неделю или две, разбивка работы на задачи и их оценка. Отслеживание индивидуальных показателей. Если есть проседание по производительности, то нужно выяснять причину. Если причина уважительная, то работа оплачивается, если неуважительная — то оплата производится по эстимейту, т.е. дополнительно потраченное время не оплачивается.
— вещи, которые год назад делались за несколько часов, сейчас требуют пары дней
— задачи выполняются невнимательно, из-за этого вылезают баги и переделки
Изначально этого человека никто не контроллировал, задачи никогда не трекались. Достаточно рассказать что сделал. Работал на совесть. Но видимо перестал.
Может семейные проблемы какие.. год назад сын родился. Но скорее всего разгильдяйство и неумение планировать свое время. Просто до рождения сына времени видимо было больше.
Работает в отдельной квартире, типа офис. Боюсь если сейчас начать крутить гайки — начнет саботировать. Пока не понятно, какие пункты выполнять сначала. Кажется что нужно делать все и одновременно.
Здравствуйте, velkin, Вы писали:
V>Прежде чем говорить о 60% нужно понять, что такое норма. Даёшь три программистских нормы за смену, родина мать зовёт.
Вот кстати да, вполне возможно, программист топик-стартера просто избаловал.
V>Мне вообще думается многие лезут не в своё дело пытаясь нанимать программистов.
V>Огласите всю сумму. Если в регионе человек согласился работать за 20 тысяч рублей, а в Москве его работа стоит 120 тысяч рублей, то дело не в рынке. А если в США он к примеру на том же самом сможет заработать 10 тысяч долларов. Если норма это то, что выдавал человек раньше, опять же по ощущениям, от самого себя, то это не норма. Есть ещё такое понятие как "технический долг", чем дольше говнокодишь, тем больше долг, тем меньше будущая производительность.
А если бы у бабки был йух?
Если чел живет и работает в США и зарабатывает 10к это норм. А если он пытается работать в США и зарабатывать 10к сидя в регионе РФ, то на его место метят 1000 таких умников и 100500 индусов.
В конце концов если ты такой умный и тебя не устраивает ЗП — нужно просто об этом сказать. Никто же не мешает искать работу в США и работать там удаленно. Да?
Про норму. Нормы как таковой конечно же нет. Но есть так условные жопочасы в неделю, которые должны вырабатываться с хорошей производительностью.
"Целеустремленность, Настроенность на результат, Позитивное мышление, Конструктивность" — эти личные качества звучат глупо и замыленно, но именно они в нормальном применении(без фанатизма) дают человеку самооорганизованность и возможность выполнять "норму". Если человек "сдувается", то все это начинает барахлить и "норма" не выполняется.
Про самоорганизованность. А накой вообще нужен программист, который не может самоорганизоваться, тем более удаленщик? Пусть в дворники идет или на завод рабочим, где его начальник организует.
Про управление. Я вообще не считаю что должен кем-то управлять. Есть технические задачи, есть деньги. Задачи надо выполнять. Программист удаленщик должен найти в себе мотивацию и самоорганизованность чтобы выполнять эти задачи за оговоренные деньги. Мое дело их проверять и принимать. Если нет — досвидания. Еще у меня куча других дел. И если я буду за одним программистом ходить постоянно, то ничего не буду успевать.
Единственное что печалит в этой ситуации, что в мозгу у программиста хранится много информации по проекту и неть возможности ее передать без потерь другому. Собственно для себя буду решать — сколько денег и времени готов вложить в сохранение этой информации и его вовлеченности.
Здравствуйте, Yodo, Вы писали:
Y>У кого есть опыт?
Просто совет: прежде чем увольнять, попробуйте найти замену и посмотреть будет ли лучше работать новый человек. Причем не спешите с выводами, подождите хотя бы 1 мес.
Возможно вы просто не компетенты оценить объем работы и то что работает мало -- лишь ваше субъективное мнение.
Да да, так и знал, что сейчас набегут опытные программисты и расскажут как руководить программистами.
Расскажут о молочных реках и кисельных берегах, о вымышленной стране где все тех процессы выстроены идеально, на каждого программиста по два менеджера и два тестера, личный психолог, личный кабинет,разделение труда, про фундамент и про говнокод, про жреца жнеца и на дуде игреца.
А я вам скажу что это полная хрень. Да, если вы западная компания, которая получила бабла от западного же фонда, вы действительно можете настроить техпроцессы, нанять архитектора, итд, итп.
При нормальном же развитии, деньги тратятся на основное, и работать здесь нужно эффективно, причем всем для того чтобы продукт приносил профит и на этот профит была возможность ввести должность архитектора и улучшить техпроцессы. И если из пяти программистов 4 это понимают и дают нормальные показатели, а один перестал понимать, то нужно ему напомнить. Кстати, если программист не умеет работать с легаси-кодом, это не программист, а кодер... на мой скромный взгляд.
Здравствуйте, Yodo, Вы писали:
Y>на каждого программиста по два менеджера
Спасибо, не надо. Фантазию-то прикрути.
Y>А я вам скажу что это полная хрень.
Разумеется, хрень. Которую ты сейчас сам себе из головы выдумал.
Y>При нормальном же развитии, деньги тратятся на основное, и работать здесь нужно эффективно, причем всем для того чтобы продукт приносил профит и на этот профит была возможность ввести должность архитектора и улучшить техпроцессы. И если из пяти программистов 4 это понимают и дают нормальные показатели, а один перестал понимать, то нужно ему напомнить.
Была у меня знакомая бизнесменша, которая всех своих сотрудников брала в долю и готова была часами с пеной у рта доказывать, что это единственный способ сделать людей заинтересованными в общем деле. А ты берёшь своих в долю? Нет? А с какой стати тогда они должны что-то там понимать, с хрена ли их должен интересовать твой профит от продукта? Нет, дядя, фантазию-то прикрути. Если они работют за зарплату, значит они работают за зарплату.
Y>Кстати, если программист не умеет работать с легаси-кодом, это не программист, а кодер... на мой скромный взгляд.
С одной стороны +1, но с другой — легаси-код тоже бывает разный. Например, если на фриланс-бирже появляется что-нибудь вида "доделать нечто, готовность 90%" — это с вероятностью 90% означает, что пилил студент-недоучка, запутался в собственном коде и сгинул. Тут выше уже сказали про энтузиазм без профессионализма. Там не код, там полный и лютый [beep], для которого любой цензурный эпитет — "запредельное спагетти", "дыра на дыре" — будет комплиментом. "Работать" с таким кодом можно только одним способом — выкинуть его нафиг сразу же, желательно не читая.
Здравствуйте, Dziman, Вы писали:
DC>> Y>- жестко поговорить (типа давай договоримся и определим график присутствия, штрафы) DC>> Y>- мягко поговорить (типа я думаю что результаты стали хуже. давай разбиремся есть ли проблема, привести в цифрах его ухудшения, дальше по ситуации). DC>> Y>- искать замену (человек выгорел?) DC>> Y>- оставить как есть и пытаться как-то оздоровлять ситуацию, чаще общаться, интересоваться, контрллировать выполненную работу. DC>> Y>У кого есть опыт? DC>> Я бы в начале попробовал 2й вариант, потом 1. Если не прокатит — то 3й D>Смысла в варианте 1 не вижу совсем, а уж тем более после 2.
Я художник, в смысле — люблю людей, несмотря ни начто.
Поэтому я поступил бы так.
Здравствуйте, Yodo, Вы писали:
Y>- вещи, которые год назад делались за несколько часов, сейчас требуют пары дней
Чтобы таких проблем не возникало, перед выполнением работы нужно требовать Task Breakdown & Estimate. Когда есть список задач с оценкой, то всегда можно поинтересоваться, почему та или иная задача занимает столько-то времени, а не столько.
Y>- задачи выполняются невнимательно, из-за этого вылезают баги и переделки
Тут тоже можно применять объективные показатели. Например, один из показателей — это количество багов на ту или иную фичу. Другой показатель — количество исправлений уже найденных багов, которые не прошли QA. Т.е. если баг, был найден QA, затем был исправлен разработчиком, и всё равно оказалось, что баг не был исправлен.
Y>Изначально этого человека никто не контроллировал, задачи никогда не трекались. Достаточно рассказать что сделал. Работал на совесть. Но видимо перестал.
Такая ситуация не является правильной. Человек — на то и человек, что может расслабиться. Поэтому и нужен менеджмент, чтобы человек не расслаблялся.
Здравствуйте, Кирилл Лебедев,
КЛ>Чтобы таких проблем не возникало, перед выполнением работы нужно требовать Task Breakdown & Estimate. Когда есть список задач с оценкой, то всегда можно поинтересоваться, почему та или иная задача занимает столько-то времени, а не столько.
Совершенно верно. Также надо не забывать выделять время на Task Breakdown & Estimate и оплачивать его.
A>Может человек стал опытней, продумывает больше наперед? Часто бывает что не вникая в специфику проще выдавать результат. Когда уже понимаешь что к чему, то продумываешь более универсальное решение, которое проще в будущем дополнить/переделать
