V>Огласите всю сумму. Если в регионе человек согласился работать за 20 тысяч рублей, а в Москве его работа стоит 120 тысяч рублей, то дело не в рынке. А если в США он к примеру на том же самом сможет заработать 10 тысяч долларов. Если норма это то, что выдавал человек раньше, опять же по ощущениям, от самого себя, то это не норма. Есть ещё такое понятие как "технический долг", чем дольше говнокодишь, тем больше долг, тем меньше будущая производительность.
А если бы у бабки был йух?
Если чел живет и работает в США и зарабатывает 10к это норм. А если он пытается работать в США и зарабатывать 10к сидя в регионе РФ, то на его место метят 1000 таких умников и 100500 индусов.
В конце концов если ты такой умный и тебя не устраивает ЗП — нужно просто об этом сказать. Никто же не мешает искать работу в США и работать там удаленно. Да?
Про норму. Нормы как таковой конечно же нет. Но есть так условные жопочасы в неделю, которые должны вырабатываться с хорошей производительностью.
"Целеустремленность, Настроенность на результат, Позитивное мышление, Конструктивность" — эти личные качества звучат глупо и замыленно, но именно они в нормальном применении(без фанатизма) дают человеку самооорганизованность и возможность выполнять "норму". Если человек "сдувается", то все это начинает барахлить и "норма" не выполняется.
Про самоорганизованность. А накой вообще нужен программист, который не может самоорганизоваться, тем более удаленщик? Пусть в дворники идет или на завод рабочим, где его начальник организует.
Про управление. Я вообще не считаю что должен кем-то управлять. Есть технические задачи, есть деньги. Задачи надо выполнять. Программист удаленщик должен найти в себе мотивацию и самоорганизованность чтобы выполнять эти задачи за оговоренные деньги. Мое дело их проверять и принимать. Если нет — досвидания. Еще у меня куча других дел. И если я буду за одним программистом ходить постоянно, то ничего не буду успевать.
Единственное что печалит в этой ситуации, что в мозгу у программиста хранится много информации по проекту и неть возможности ее передать без потерь другому. Собственно для себя буду решать — сколько денег и времени готов вложить в сохранение этой информации и его вовлеченности.
Здравствуйте, dimgel, Вы писали:
V>>Мне вообще думается многие лезут не в своё дело пытаясь нанимать программистов. D>Вот эту мысль недопонял, разверните пожалста.
Предположим у некоего человека достаточно денег, то есть в принципе он уже может нанять каких-либо программистов. Естественно он не меценат и за это ему нужно исполнение некой хотелки. Даже бывшие или практикующие программисты могут не представлять всю сложность разработки программного обеспечения, а уж люди далёкие от разработки тем более.
Для понимания используют различные приёмы, тот же метод аналогий. Взять строителя, что бы он мог подумать о программистах. Разработчики это рабочие, а руководит ими прораб, то есть тим-лид. Если у него чуть более богатая фантазия, то он может вспомнить, что ещё нужен архитектор, а программа это здание. Мышление аналогиями привлекательно, так как объясняет незнакомые вещи знакомым языком, но к сожалению это самообман.
На самом деле строитель бы до этого не додумался. Он бы скорее ограничился моделью построения здания с помощью низшего рабочего звена. Есть некий человек, который делает всё, заливает бетон, выкладывает стены, коммуникации, водопровод, электричество, перекрытия, ставит окна, крышу, в конце идёт люксовая отделка, и всё это должно быть точно таким, как по ходу дела возникнет в голове у заказчика, но сумма фиксируется сразу, рабочему платят по рынку.
А чертежи и планы вообще не нужны, заказчик с гордо поднятым носом заявляет, что он платит за дом, а не всякие бумажки. Если же супер рабочий будет филонить, то не беда, в строительном бизнесе вместо одного каменщика, нанимаешь другого, и так во всём. Только строитель может подзабыть, что у супер рабочего нет чертежей, а здание у него как из фильма Тёмный город, постоянно трансформируется на ходу по желанию владельца.
Суть в том, что бизнес не связанный с созданием программных продуктов, но кому понадобилось индивидуальное решение пытается нанять программистов, которым можно полностью делегировать полномочия по управлению проектом. Но те, кому по-настоящему можно передать полномочия, могут открыть свою фирму и работать по дорогим контрактам, нежели за зарплату обычного кодера.
К тому же все на чём-то учатся, и пока это происходит кто-нибудь непременно терпит убытки. Потому обученный человек и стоит дорого, что он сразу работает и не приносит убытков из-за обучения. Мне, например, нельзя доверять управление программистами, то есть можно, но пока я обучаюсь у любой фирмы пойдут убытки. Если бы у меня был руководитель и он спросил, сколько осталось до того, чтобы сделать это и это, то для меня он бы расписался в собственной некомпетентности, так как это явная попытка делегировать мне его полномочия.
Вернутся к той же теме. Если бизнес не компетентен, а в данном случае всё выглядит именно так, то у него остаётся всего лишь один надёжный критерий. Или он готов платить текущую зарплату за текущую работу, или не готов. Без всяких там норм выработки и прочей бодяги. У американцев же есть поговорка, делай или плати. Или надо делать самому и качественно, или платить и смотреть на результат. А розовые мечты, что можно уволить и нанять фрилансера с 300% некой нормы, всего лишь мечты.
Может так и получится, а может будет один процент от нормы, с последующим сливом работодателя и так по цепочке от фрилансера к фрилансеру. Говорить с человеком о проекте я считаю в любом случае надо. Составлять требования, прояснять непонятные моменты. Жёсткие и мягкие угрозы, в том числе увольнение, это уже на любителя. Работал с человеком, всё устраивало, хотя может быть хотелось бы лучше. Потом на форуме какой-нибудь Вася Пупкин из девятого бэ класса посоветовал уволить фрилансера и его тут же уволили. Это смешно.
Здравствуйте, Yodo, Вы писали:
Y>В конце концов если ты такой умный и тебя не устраивает ЗП — нужно просто об этом сказать. Никто же не мешает искать работу в США и работать там удаленно. Да?
Да, потому если не нравятся услуги фрилансера, точно так же можно ему об этом сказать. Это его скорее демотивирует, но зато, когда вы расстанетесь, платить ему уже будет не нужно.
Y>Про самоорганизованность. А накой вообще нужен программист, который не может самоорганизоваться, тем более удаленщик? Пусть в дворники идет или на завод рабочим, где его начальник организует.
Лучший выход пойти на "завод по производству программ", там и зарплаты высокие и организуют люди у которых зарплата ещё выше. На российский завод главным результатом труда которого являются не программные продукты, ни рабочим, ни программистом, лично я, идти не рекомендую.
Y>Про управление. Я вообще не считаю что должен кем-то управлять. Есть технические задачи, есть деньги. Задачи надо выполнять. Программист удаленщик должен найти в себе мотивацию и самоорганизованность чтобы выполнять эти задачи за оговоренные деньги. Мое дело их проверять и принимать. Если нет — досвидания.
Если результат труда не устраивает, расставайтесь, да и всё. Сейчас это в моде. Главное не забывайте, что мотивированный дурак не сможет заменить даже одного не мотивированного специалиста. Мотивация не заменит компетентность. Вообще, под излишне сильную мотивацию при недостатке умений, очень хорошо говнокодить. Тема мотивации обширна, обычно рекомендуют подумать на тем, чем сотруднику может быть интересен проект, кроме денег. Но мотивация ладно, а вот самоорганизация это уже не какая-то там мотивация, она достигается лишь очень высокой квалификацией.
Y>Единственное что печалит в этой ситуации, что в мозгу у программиста хранится много информации по проекту и неть возможности ее передать без потерь другому. Собственно для себя буду решать — сколько денег и времени готов вложить в сохранение этой информации и его вовлеченности.
Это издержки отказа от управления. Можно создать артефакты системного анализа, но на это программист тоже должен тратить время и иметь более высокую квалификацию, чем просто кодер. Модифицируемость программного продукта важная характеристика. Впрочем может быть следующий фрилансер скажет, что ему проще всё заново переписать.
Здравствуйте, 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>Если человек не может нормально работать только потому что ему не пообещали долю, проблема в нем.
+1.
Y>Да, представь себе: работать нормально без доль, расти вместе с продуктом, который делаешь. Да, такие люди есть, да такие люди четко, слаженно и позитивно работают стремясь сделать продукт лучше. Если дела пошли в гору, Y>такой человек просто подходит и говорит "у нас все ок, не пора ли увеличить мои доходы", а я в свою очередь предлагаю увеличение ЗП заранее, как только есть такая возможность. Включи фантазию — такое бывает.
Да я как бы в курсе, что бывает. Но я сильно сомневаюсь, что такое может возникнуть само по себе, без усилий и понимания психологии со стороны руководителя. Т.е. руководители, у которых такое бывает, достаточно мудры сами по себе, чтобы спрашивать тривиальные и базовые для управленца вещи на форумах. И зарплату, кстати, не "предлагают увеличить", а тупо "увеличивают". Есть у меня, кстати, сомнения, что вы этим действительно сами хоть раз занимались просто от широты душевной, без намёков со стороны работников: кто способен сам принять решение о повышении зарплаты хорошему сотруднику, тот и решение об увольнении плохого примет без подсказок.
Здравствуйте, Yodo, Вы писали:
Y>Сейчас у него нет графика вообще. Когда хочет, тогда и работает. Человек свой график не выстраивает и работает, когда может (т.е. родители из района на другом конце города позвонили — попросили приехать кран починить, он поехал или собаку на прививку повез внутри дня) вроде все ок. Но последнее время(несколько месяцев) стал выдавать результаты меньше, по ощущениям около 60% от нормы. ЗП по рынку.
Может человек стал опытней, продумывает больше наперед? Часто бывает что не вникая в специфику проще выдавать результат. Когда уже понимаешь что к чему, то продумываешь более универсальное решение, которое проще в будущем дополнить/переделать
Здравствуйте, Yodo, Вы писали:
Y>- вещи, которые год назад делались за несколько часов, сейчас требуют пары дней
Чтобы таких проблем не возникало, перед выполнением работы нужно требовать Task Breakdown & Estimate. Когда есть список задач с оценкой, то всегда можно поинтересоваться, почему та или иная задача занимает столько-то времени, а не столько.
Y>- задачи выполняются невнимательно, из-за этого вылезают баги и переделки
Тут тоже можно применять объективные показатели. Например, один из показателей — это количество багов на ту или иную фичу. Другой показатель — количество исправлений уже найденных багов, которые не прошли QA. Т.е. если баг, был найден QA, затем был исправлен разработчиком, и всё равно оказалось, что баг не был исправлен.
Y>Изначально этого человека никто не контроллировал, задачи никогда не трекались. Достаточно рассказать что сделал. Работал на совесть. Но видимо перестал.
Такая ситуация не является правильной. Человек — на то и человек, что может расслабиться. Поэтому и нужен менеджмент, чтобы человек не расслаблялся.
Здравствуйте, Кирилл Лебедев,
КЛ>Чтобы таких проблем не возникало, перед выполнением работы нужно требовать Task Breakdown & Estimate. Когда есть список задач с оценкой, то всегда можно поинтересоваться, почему та или иная задача занимает столько-то времени, а не столько.
Совершенно верно. Также надо не забывать выделять время на Task Breakdown & Estimate и оплачивать его.
Здравствуйте, Yodo, Вы писали:
Y>- вещи, которые год назад делались за несколько часов, сейчас требуют пары дней Y>- задачи выполняются невнимательно, из-за этого вылезают баги и переделки
Так, анамнез собрали. Теперь надо переходить к анализам, потому что симптомы могут соотвествовать куче различных причин. Про "баги и переделки" хотелось бы услышать подробнее. Они могут выглядеть по-разному:
1. Было забыто то, что явно упоминалось в письме.
2. Было не сделано то, что подразумевалось или что-то не совсем так работает.
3. В результате отвалилось что-то, не связанное с исходной задачей.
В результате анализа ошибок можно уже строить гипотезы, уточнять их и потом действовать по обстоятельствам. Группы далее примерно соответствуют категориям выше.
Первая группа — это невнимательность. Может вызываться различными причинами. Начиная от снижением мотивации и заканчивая банальной усталостью. Решения — от смены сотрудника до предоставления ему обязательного оплачиваемого отпуска.
Вторая группа — коммуникационные проблемы (с обеих сторон). В течение года у вас выработался некоторый язык и появились "умолчания". Проблема только в том, что умолчания сейчас воспринимаются по-разному с вашей стороны и со стороны разработчика. В результате получается не то, что вы хотели. Не потому, что программист потерял мотивацию. А потому, что задачи стали менее детальными (больше умолчаний). Решается признанием проблемы и настройкой коммуникации. В качестве первого шага можно попробовать давать более подробные задания. Можно описать ситуацию разработчику и попросить обратную связь от него. Смена разработчика может улучшить ситуацию. Но не из-за мотивации, а в силу процесса начальной "притирки" друг к другу, когда умолчаний в общении будет меньше. Зато новый разработчик ваш проект не знает. Так что я бы порекомендовал сначала общаться с тем, кто есть.
Что интересно, вторая группа может быть связана как с первой, так и с третьей. Например, при накопленной усталости все умолчания и неявные требования воспринимаются хуже или просто не замечаются. А может быть, в процессе написания детальных требований вы обнаружите, что не все так просто и имеется в наличии третья группа проблем.
Третья группа — проект достиг критической массы. Добавлять новую фичу в проект с тремя функциями и с двумя десятками разных функций — огромная разница. В первом случае это гораздо проще. Во втором случае нужно следить за тем, чтобы все работало как прежде. Еще и требования желательно подогнать под остальные функции. Вот строите вы дом. Пока есть один-два этажа, там все можно поменять. Когда есть уже 15 этажей, переделки будут медленнее. "Поставить эскалаторы в добавок к лифтам" проще делать в маленьком доме. Видите разницу? Т.е. замедление может быть вызвано самим усложнением проекта (essential complexity). А также оно может быть вызвано ухудшающимся качеством кода (спагетти и прочие ужасы технического долга). Причем долг может быть как осознаваемый программистом, так и не осознаваемый им, что дает совершенно разную картину. Плюс долг снижает мотивацию, это тоже нужно учитывать. Год — вполне достаточный промежуток, чтобы начали проявляться подобные эффекты сложности проекта/кода.
В третьей группе действия и прогнозы будут разными.
Essential complexity можно легко найти. Попробуйте писать более подробные требования. Вы сразу (ну не сразу, а по результатам анализа упущений в требованиях) заметите связность различных фич и сложность проекта. Можно просто смириться или попробовать упростить требования. Точнее, перегруппировать их и сделать менее связными (заодно и пользователям приложения может стать лучше). На требования разработчик мало влиять может. Так что применять к нему какие-нибудь меры (кроме просьбы помочь разобраться в ситуации) смысла нет.
Осознанный технический долг. Прогноз положительный, но тоже нужно общаться. Поговорите с программистом. Изложите свои проблемы. Может быть, он уже давно хочет что-то изменить/переписать. Сделаете оплачиваемый рефакторинг/реинжиниринг вместо нескольких фич. Вернете скорость и мотивацию повысите.
Неосознанный технический долг. Здесь прогноз уже далеко не такой положительный, так как реальной проблемы и пути исправления никто не видит. Можно как-то попробовать мотивировать разработчика искать более глубинные проблемы. Но вы должны понимать, что в случае успеха вы пройдете "осознанный технический долг", после чего производительность программиста повысится (он теперь имеет более широкий кругозор) и вам придется поднять ему зарплату или предоставить больше свободного времени. Можно попробовать получить консультацию других разработчиков. Или нанять кого-нибудь другого (можно в параллель, чтобы обучить вашего). И готовьтесь к тому, что вам в итоге предложат все переписать. Ну или последовательно отрефакторить от 10 до 80% приложения. Запущенный технический долг — он такой. Обычно вызван недостатком квалификации на момент написания кода, так что метастазы можно найти по всему приложению.
Итого.
Как видите, в большинстве вариантов лучший путь — прямой диалог. Только сначала нужно более детальную статистику собрать по типам проблем. Мотивации может дать временный эффект, но в большинстве случаев картину радикально не изменит, да и правильный метод выбрать сложно. Смена сотрудника может помочь в отдельных случаях (либо первая группа, либо неосознанный долг из третьей), но при этом работают все стандартные риски смены сотрудников.
Так что анализируйте проблему глубже. Ну и общайтесь, конечно.
A>Может человек стал опытней, продумывает больше наперед? Часто бывает что не вникая в специфику проще выдавать результат. Когда уже понимаешь что к чему, то продумываешь более универсальное решение, которое проще в будущем дополнить/переделать
A>Может человек стал опытней, продумывает больше наперед? Часто бывает что не вникая в специфику проще выдавать результат. Когда уже понимаешь что к чему, то продумываешь более универсальное решение, которое проще в будущем дополнить/переделать
Я бы перефразировал:
Когда уже понимаешь что к чему, то перестаёшь придумывать более универсальное решение, которое и сложнее и никому никогда не потребуется, а делаешь то что реально проще в будущем дополнить
