А в это время

    – Нет, так дело не пойдет! – почти кричал взбешенный Анатолий Викторович. – Я не понимаю, за что плачу такие – заметьте, не малые – деньги! Чем программисты лучше других? Они что, какие-то особенные?


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


    – Вот этими сказками я уже сыт по горло, про таинство творческих профессий! Слава Богу, у нас еще дизайнеров нет... Инженеры-конструкторы тоже постоянно на творчество ссылаются.


    – Елена Анатольевна, вы, как HR, что можете сказать? – после минутной паузы, немного успокоившись, спросил Анатолий Викторович. – Неужели нет практик по измерению работы программистов? Что, весь мир мучается, платит огромные деньги и не понимает, за что? Неужели нет возможности программирование отехнологичить, нарисовать в виде процесса, измерить, установить критерии?


    – Можно, конечно, Анатолий Викторович. – Чуть запинаясь и, кажется, краснея от волнения заговорила Елена Анатольевна. – Есть несколько методов, многие – довольно объективные. Например, измерение объемов программного кода.


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


    – Погодите, а разве количество строк кода и сложность, да и трудозатраты, однозначно связаны? – спокойно, но с некоторой долей иронии проговорила Татьяна Владимировна.


    – Конечно, для каждой конкретной задачи зависимость будет плавать. – сбивчиво затараторила Елена Анатольевна. – Но в целом, в среднем, в объеме – этим цифрам вполне можно доверять.


    – Давайте пробовать! – энтузиазм Анатолия Викторовича был неудержим. – Как запустить такую систему? Какие нормативы?


    – Я все сделаю, Анатолий Викторович! – с явно картинной решительностью, громко и четко произнесла Елена Анатольевна. – Принцип нормирования простой: смотрим количество строк кода за последние 3 месяца, смотрим сумму окладов, делим одно на другое – получаем расценку. Немного увеличиваем, чтобы было к чему стремиться – и вперед!


    – Действуйте!


    А в это время в ИТ-отделе


    – Чего они там опять придумали? – тяжко вздохнув, спросил Колян.


    – Измерять количество строк кода, и за них платить нам зарплату. – сказал Сергей.


    – Блин, вот дебилы. Не понимают что ли – чем меньше кода, тем лучше?


    – Ну поди им объясни. – недовольно процедил Сергей. – Я говорил с новой ХаРэ, ей пофиг, выслужиться хочет.


    – А в чем выслужиться-то? Новую бессмысленную систему мотивации програмистов сделать? – не унимался Колян.


    – Стать первой в мире теткой, обуздавшей программистов. – с улыбкой произнес Сергей.


    – Вот корова блин. Не на тех напала! Мы ей столько строк кода выдадим, что считать запарится!


    – Да тут и думать нечего, херачим по полной. Никакой оптимизации, повторного использования кода, абстракций и прочей ереси. Эх, не думал никогда, что такие вещи буду ересью называть...


    – О, вот еще идея! Давай больше не будем зависимости использовать! -радостно вскрикнул Колян.


    – Это как, без зависимостей-то? React выкинуть? Pouchdb? Alasql? С дуба рухнул? Навернется же система.


    – Не, ты не понял. Использовать будем, только пусть они не в node_modules лежат, а в наших папках. Ну типа мы сами их пишем. Тупо код в свои модули копируем, аккуратно, чтобы все классы с методами на местах остались, и строки себе в зачет ставим!


    – Шаришь, Колян! А если кто докопается, скажем, что это – форк с нашей оберткой, потому что в чистом виде для наших целей не годится.


    – Ага, и весь прогрессивный мир будет на нашу зарплату пахать, сам того не зная!


    – Ну, главное – не переборщить, чтобы в глаза не бросалось сильно.


    – Само собой, мы ж не дураки.


    А в это время в кабинете директора


    – Наталья Геннадьевна, я уверен, что вы – профессионал высочайшего класса, и сможете создать эффективную систему измерения труда программистов. – устало начал Анатолий Викторович.


    – Да, у Елены Анатольевны, вашей предшественницы, не очень получилось. – с пространной улыбкой сказала Татьяна Владимировна.


    – НЕ ОЧЕНЬ ПОЛУЧИЛОСЬ? – мгновенно вспыхнув, вскочил со стула Анатолий Викторович. – За квартал использования системы я заплатил программистам вдвое больше денег! Притом, что меня спасло заложенное в систему ограничение – не более двух окладов!


    – Ну да, и притом, что Елена Анатольевна каждый месяц вдвое увеличивала им нормы. – примирительным тоном сказала Татьяна Владимировна. Получается, наши программисты способны выдавать в шесть раз больше кода за те же деньги.


    – А функциональность системы почти не меняется. Зачем тогда весь этот код? В разы, в десятки раз больше кода? Если толку для бизнеса – ноль.


    – Да, вероятно, была ошибка в системе расчета. – продолжала Татьяна Владимировна.


    – Это не ошибка, Таня, это ущербность. И системы, и специалиста, ее придумавшего. – немного успокоился Анатолий Викторович. – Ну ладно, дело прошлое. Слава Богу, мы вовремя одумались, остановили эту, с позволения сказать, мотивацию и расстались с Еленой Анатольевной.


    – Теперь вся надежда на вас, Наталья Геннадьевна. – усевшись обратно за стол, продолжил Анатолий Викторович. – Как, кстати, правильно – Наталья или Наталия?


    – Наталья. Но мне без разницы. – уверенно проговорила Наталья Геннадьевна.


    – Ну ладно, а то у нас есть финансовый директор, всю плешь проела с тем, что она Наталия. Буквально перестала на письма отвечать, если мягкий знак ставят.


    – Мне важно содержание, а не форма. – строго и четко начала Наталья Геннадьевна. – Количество строк кода – это форма. Решенная строками кода задача – это содержание. Значит, измерять и платить надо за задачи – решенные, отлаженные, принятые заказчиком, с понятной пользой для компании.


    – Это распространенная практика? – На этот раз Анатолий Викторович решил не соглашаться сразу.


    – Да, конечно. – все более уверенно и твердо продолжала Наталья Геннадьевна. – Распространенная, потому что простая и естественная. Проекты, процессы, цели – это все надстройки, в основе которых лежат атомарные сущности – задачи.


    – Такое ощущение, что с программистом разговариваем. – засмеялась Татьяна Владимировна. – Атомарные, сущности. Они еще часто метрики упоминают.


    – Само собой, метрики, только у нас это называется KPI, или КПЭ. – нисколько не смутившись, продолжила Наталья Геннадьевна. – Я не программист, но у меня большой опыт работы с этой категорией сотрудников.


    – Не-не, я ничего плохого в виду не имела. – Татьяна Владимировна сделала вид, что смутилась. – Наоборот, ваше знание специфичной терминологии дает нам уверенность, что вы хорошо знаете специфику работы программистов.


    – И сможете их, наконец, оцифровать! – хлопнув ладонями по столу, подытожил Анатолий Викторович.


    – А что именно вы сделаете основой для расчета? – поинтересовалась Татьяна Владимировна.


    – Количество решенных задач. Объем трудозатрат в задачах бывает разным, но всегда есть средний чек, как в ресторанах. Его и возьмем за основу. Хочешь получать больше – решай больше задач. Все.


    – Действуйте!


    А в это время в ИТ-отделе


    – Чего они там опять придумали? – недовольно пробурчал Колян.


    – Слушай, Колян, ты прям как корова, которая… – начал было Сергей.


    – А в дыню? Какая еще корова. – возмутился Колян.


    – Да погоди ты, бык театральный, дослушай сначала. – примирительно сказал Сергей. – Сказку помнишь, про Крошечку-Хаврошечку? Которая приходила к корове со своей бедой, та говорила типа влезь ко мне в ушко, вылезь в другое, и будет тебе счастье. Ну или как Конёк-Горбунок.


    – Ладно, живи. Так чего там нового в оценке нашей, прошу прощения, работы?


    – Будут считать количество задач, и на основе этого количества платить зарплату.


    – Блин, это даже скучно. – Колян лениво почесал пузо. – А что, код теперь не надо генерировать?


    – Нет, с этим все.


    – Ну Слава Богу, наконец-то вернем зависимости. Я задолбался в диффы react’а пялиться.


    – Что, у тебя и готовое решение есть? По задачам?


    – Какое готовое решение, ты чего, как маленький. Эх, чему вас только в вашей Бауманке учат. Даже мне, ПТУшнику, понятно, что надо просто увеличить количество задач.


    – Ну и как это сделать? Задачи-то пользователи ставят.


    – А где написано, что только пользователи могут ставить задачи? – хитро прищурился Колян.


    – А это мысль… Давай я в должностной инструкции и процессе гляну?


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


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


    – Ну и прекрасно! – сказал довольный Колян. – Только наглеть не надо, давай и через пользователей задач нафигачим.


    – Это как? Мы со всеми переругались, пока код генерировали. – спросил Сергей.


    – Мы-то со всеми, а один чувачок сохранил старые связи.


    – Ты про кого? Про Бородатого что ли?


    – Про кого же еще. Стасян! – громко позвал Колян.


    – Ау! – отозвался Стас.


    – Чего ау, в лесу заблудился что ли? Давай, чеши сюда. – взмахом руки подозвал Колян. – Давай, короче, выручай отдел, ты нам нужен, мы же команда, бла-бла-бла.


    – Задолбал, говори, чего надо – недовольно пробормотал Стас.


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


    – Э… А им-то это нафига? Как я их убеждать буду?


    – Блин, а как ты их убеждаешь прибегать по утрам и целовать тебя в щечку? – засмеялся Колян. – Пригрози лишить их этого… Ну как его… Чем ты их там наделяешь… Вот этого и пригрози лишить.


    – Ну вы злые. – картинно возмутился Стас.


    – Да, и это: одна хотелка – одна задача. Это всех касается. Не нужны нам портянки со списками требований.


    – Это уже перебор, заметят, докопаются. – начал волноваться Сергей.


    – Не, я недавно в блоге Лебедева читал, что это – крутой лайфхак, когда в одном сообщении или задаче – одна тема или проблема.


    – А, ну ладно тогда. Ссылку кинь, я сохраню себе.


    – Не вопрос.


    А в это время в кабинете директора


    – Ну, Галина Сергеевна, вы все знаете. – голос Анатолия Викторовича звучал очень устало. – Еще на собеседовании мы рассказали вам о проблеме с программистами, и о неудачных попытках, предпринятых предыдущими директорами по персоналу. Я, если честно, уже не верю в то, что задача измерения их работы может быть решена.


    – Напрасно, Анатолий Викторович! – Галина Сергеевна выглядела (всегда) на редкость жизнерадостно. – Просто были использованы устаревшие практики. Очень устаревшие. Я прошу прощения, некрасиво осуждать своих предшественников, у нас есть негласный кодекс, как у врачей. Но, тем не менее…


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


    – О, да сколько угодно! Первый вариант, с количеством строк кода, устарел лет двадцать назад. В те времена почти весь код писал сам программист, не было заимствований, шаблонов, готовых модулей и библиотек. Строка кода была… Как это выразить… Ну короче, это была СТРОКА. Местами даже был построчный ввод, когда ее потом нельзя было редактировать. Еще какие-то перфокарты были, бумажки такие, которые уже не исправишь. Вот тогда строка была нормальной единицей измерения.


    – А второй вариант, с задачами?


    – Это неплохой вариант, но не для внутреннего ИТ-отдела большого производственного предприятия, а, например, для интегратора или чисто ИТшной компании, работающей с поддержкой в трекере. Там задачи, действительно, в среднем похожи, и на основе их количества можно понимать вклад каждого сотрудника. В случае же серьезного бизнеса, как наш, такой подход не годится.


    – Еще как не годится! Как в песне, я прошу прощения, пахабной – «вдруг, откуда ни возьмись, появился в рот е*ись!». – возмутился Анатолий Викторович. – Оказалось, что наши сотрудники только и ждали возможности понаписать задач в ИТ-отдел! В три раза больше написали, чем когда-либо прежде!


    – Да, это издержки позадачного подхода. Традиционная ошибка. – с улыбкой произнесла Галина Сергеевна.


    – Хорошо, а вы что предлагаете? – спросила Татьяна Владимировна.


    – Проектный подход. Нас, то есть бизнес, не интересует код, не интересуют задачи. Только результат, выраженный в достижении критериев успешности проекта. Сделал проект – получи премию. Не сделал проект, неважно, по какой причине – сиди ночами, в выходные, доделывай. Если хочешь премию, разумеется.


    – Погодите, проекты же длинные, в месяц больше одного не уложишь. – засомневалась Татьяна Владимировна.


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


    – Я боюсь опять ошибиться. – начал Анатолий Викторович. – Но проектный подход мне нравится. Он мне понятен. Есть конкретный руководитель, есть критерии, есть качественный скачок функциональности.


    – Разумеется, это самый современный подход. – поддержала Галина Сергеевна. – Весь мир живет проектами, в том числе на государственном уровне. Не пристало бизнесу копаться в задачах и программном коде. Только результаты, только проекты.


    – Мне нравится! Действуйте!


    А в это время в ИТ-отделе


    – Ну давай умник, придумывай, как теперь будем выкручиваться. – ехидно спросил Сергей.


    – Чего, опять власть меняется? – недовольно спросил Колян.


    – Да, теперь все серьезно. Нет задач, есть проекты. Да, и премия теперь квартальная, а не месячная.


    – Блин, да что у них там с головой… Как будто сгноить нас тут хотят…


    – Ну а ты чего хотел… Может, п-р-о-с-т-о р-а-б-о-т-а-т-ь н-а-ч-а-т-ь? – нараспев проговорил Сергей.


    – Просто работать – просто получать. Они ж нас замотивировать хотят, на какие-то, прошу прощения, достижения. Вот и получают достижения.


    – Ладно, лирику в сторону. Делать что будем?


    – Есть какие-то бумажки, регламенты, или чего там? Как будет работать новая система?


    – Да, у меня в почте. Скинуть почитать?


    – Да, давай. И отвали на полчаса, Чапай думать будет.


    Через 15 минут диалог возобновился.


    – Ну, пациент скорее жив, чем мертв. – с легкой ухмылкой проговорил Колян.


    – Давай, рассказывай, я весь в нетерпении. – Сергей сказал правду.


    – Ну, смотри, главное – критерии успешности определяет руководитель проекта.


    – Это очевидно, на то он и руководитель.


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


    – Ой, только давай не будем опять просить Бородатого, чтобы он превратил девочек-логисток в руководителей проектов. Такой номер точно не прокатит.


    – Такой нет, а вот ты, засранец эдакий, с твоими степенями и дипломами, вполне на такую роль сгодишься.


    – Сгодиться-то сгожусь, а толку-то? К нам сейчас очередь выстроится из хочунов проектов, в лице руководителей отделов. – уныло пробормотал Сергей.


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


    – Пока нет, если честно…


    – Ну ты дурья башка… Руководить проектом разработки и внедрения информационной системы – это не только почетно, но и адски трудно, если заниматься этим серьезно. Согласование требований одно чего стоит.


    – А чего оно стоит? Если он сам требования написал.


    – Это ему так кажется, что он для своего отдела написал. Вот кто придет? Служба снабжения? Личные кабинеты поставщиков попросит?


    – Да, думаю придет, давно ноют про свои кабинеты.


    – Так вот, сразу запускаем адский круг. В личном кабинете будут договоры – так? Типовые, шаблонные, но это пофиг. Пусть идет в юридический отдел согласовывать.


    – Ну, допустим, сходит.


    – Потом в бухгалтерию, потому что там будут счета на оплату и накладные. Так?


    – Так.


    – Половина, так сказать, заказчиков, сдастся на этом месте. Там ведь надо не только свой автограф поставить, но и реально согласовывать требования. А тот же начальник снабжения – ни в зуб ногой в тех же накладных и особенностях Российской Системы Бухгалтерского Учета.


    – Ну, допустим, без нас он этого сделать не сможет. И что с того? Что дальше?


    – Дальше – как в сказке. Надо согласовать процедуру проверки поставщиков со службой безопасности. А кто лучший друг службы безопасности?


    – Не знаю, кто?


    – Да что с тобой сегодня… Петрович их лучший друг.


    – Петрович? Как сисадмин стал лучшим другом СБ?


    – Как-как… Установил следилку на все компы, все логи им дает, уже пропарсенные, индексированные, чуть ли не классифицированные по вероятности угрозы. А кто начальник Петровича?


    – Я.


    – А больше похоже, что я. – уже немного агрессивно напирал Колян. – Ты пойми главное: надо создать ощущение невозможности управления проектом ИТ. Нет, не так… Ощущение невыносимости!


    – Так он просто спрыгнет, и вместо него придет другой.


    – А ты, Сережа, ворон-то не считай, будь рядом с человеком, подставь плечо, поддержи. Ну как эти, которые возле ГИБДД помогают за пару тысяч рублей договор купли-продажи оформить. Или как риелторы. Ну ты понял. Чтобы он всегда понимал обходной путь.


    – А в чем он заключается-то? Что мы поможем бумажки оформить что ли?


    – Слушай, не беси меня. Ты можешь сам руководить проектами ИТ. Это нормально, понятно и современно. А человеку дашь какую-нибудь почетную должность, я не знаю. Заказчик проекта, или куратор проекта – сам придумай.


    – А, все, теперь понял.


    – Ну Слава тебе, Господи. – удовлетворенно вздохнул Колян. – Только этого мало. Надо еще сами генерить проекты.


    – Это как? Внутренние какие-то, технические что ли?


    – Нет. Ты же знаешь, чего надо продавцам?


    – Ну так, примерно… CRM надо.


    – Так и инициируй проект по внедрению CRM. Пусть знают, что ИТ-отдел не только исполнять может, но и предлагать. Так сказать, проактивно улучшать деятельность компании.


    – А в чем смысл?


    – Кто первый встал, того и тапки. – раздраженно сказал Колян. – Кто инициировал проект, тот им и руководит. Особенно, если проявить настойчивость, задолбать начальника отдела продаж своими предложениями. Они ж все занятые, им некогда такой фигнёй заниматься, как руководство проектом. А тут ты, спаситель на белом коне – всю рутину и бумажки берешь на себя, декомпозицию делаешь, задачами управляешь, критерии пишешь, уставы там, и всю бюрократию. Они только результат получают.


    – А, понял. Ладно, давай пробовать.


    – Чего пробовать, делать давай. Поднимай процедуру инициации проекта, изучай, и вперед.


    – Ладно, понял.


    А в это время в кабинете директора


    – Алексей, спасибо, что так быстро откликнулись. – бодро начал встречу Анатолий Викторович. – Вам удалось изучить материалы по системам мотивации, которые мы присылали?


    – Да, почитал в самолете.


    – Что скажете?


    – Неплохие системы, если в целом. Но – морально устаревшие, если говорить про программистов.


    – Я тоже так думаю, и реальность мои мысли только подтверждает. – стараясь выглядеть уверенно, сказал Анатолий Викторович. – К сожалению, мы слишком часто и много доверяли нашим специалистам по HR. Больше я такой ошибки совершать не хочу, потому и пригласил вас.


    – Алексей, а можно в двух словах о вашем опыте работы с программистами? – вступила в диалог Татьяна Владимировна.


    – В этом нет нужды, Таня. – осек ее Анатолий Викторович. – Алексей преподавал нам курс по системам мотивации в EMBA, в Сколково. У меня нет сомнений в его компетенциях.


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


    – О, спасибо, то, что нужно. – улыбнулась Татьяна Владимировна. – Обязательно изучу.


    – Итак, Алексей, с чего думаете начать?


    – С договора, разумеется. – с сухой улыбкой ответил Алексей. – Я высылал типовую форму вам на почту вчера, там же есть спецификация конкретно под ваш проект.


    – Да, я получил. – ответил Анатолий Викторович. – Отдал на согласование в юридический отдел, это стандартная процедура. Тань, проследи, пожалуйста, чтобы не затягивали и не мудрили там. Я Алексею доверяю полностью.


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


    – Нет, по сумме все понятно, я такого примерно и ожидал. Специалист такого уровня не может стоить дешево. Там, насколько я помню, 8 миллионов?


    – Да, это за всю систему мотивации, на весь периметр компании.


    – Хорошо. Только личная просьба – удели, пожалуйста, особое внимание программистам.


    – Не вопрос. У меня, собственно, уже есть решение для них. Осталось только уточнить детали.


    – Расскажешь, в двух словах? – оживился Анатолий Викторович. – Три варианта я уже видел, трех директоров по персоналу пришлось выгнать. Сейчас там Елена Борисовна, новый специалист, она полностью в твоем распоряжении.


    – Ключевой ошибкой всех прошлых систем мотивации была ориентация на выработку, неважно, в какой единице измерения – проекты, задачи, код и т.д. – уверенно начал Алексей. – Так уже давно никто не работает. Слишком сложно, слишком затратно, слишком зыбкая это основа – выработка программистов.


    – А как, в чем секрет, как их измеряют серьезные компании? – сгорал в нетерпении Анатолий Викторович.


    – Грейды.


    – Грейды?


    – Да, грейды. Вспомните, на эту тему была одна из лекций в EMBA.


    – Не припомню, если честно… – замялся Анатолий Викторович. – Некоторые занятия я пропустил, по объективным причинам.


    – Анатолий Викторович… – протяжно произнесла Татьяна Владимировна. – Сто тысяч евро за курс, а вы пропускаете занятия.


    – Ну, в конце концов, это мои деньги, Татьяна. – немного обиженно протянул Анатолий Викторович. – Хотя, конечно, каюсь, не безгрешен.


    – Грейды – это современная система распределения оплаты в зависимости от квалификации сотрудника. – четко проговорил Алексей. – Каждый грейд – это набор компетенций, навыков, обязанностей и результатов, которые должен достигать сотрудник. Соответственно, каждый грейд – это отдельный уровень оплаты труда. Чем выше грейд, тем выше доход.


    – Это как… Квалификация что ли? У инженеров-конструкторов наших. Первая там, вторая, третья вроде есть? – на первый взгляд невинно спросила Татьяна Владимировна.


    – Определенное сходство есть, разумеется. Ничто не ново под этой луной. – на лице Алексея появилась не очень уверенная улыбка. – Но квалификации инженеров, в первую очередь, зависят от стажа работы на соответствующих должностях. Грейды же привязаны к квалификации, а не к стажу работы. Хотя, в определенных случаях, чтобы учесть опыт, вносится пункт о стаже.


    – А, вон как… Примерно поняла разницу, спасибо.


    – Окей, тогда, если нет возражений, я пойду поработаю с вашим HR. Думаю, в течение нескольких дней грейды будут готовы. Я лишь соберу некоторую информацию по вашим программистам, системам, фреймворкам и отдам ее для изучения своим аналитикам, чтобы те прикинули градацию компетенций.


    – Возражений нет! – бодро выпалил Анатолий Викторович. – Действуй!


    А в это время в ИТ-отделе


    – О, по лицу вижу, чего-то нового тащит! Давай, заходи, садись, рассказывай. – Колян был в прекрасном расположении духа.


    – Да пипец… Опять новая система мотивации… – с потухшим взглядом заговорил Сергей. – На этот раз не выкрутимся, по-серьезному за нас взялись.


    – Это кто взялся? Тот хлыщ московский?


    – Ты откуда знаешь?


    – От верблюда. Петровича вызывали, вай-фай ему включал на маке. Акцент, говорит – мама не горюй!


    – Понятно. Короче, теперь у нас грейды.


    – Грейдер?


    – Блин, колхоз восьмое марта. Грейды, от английского “grade”, видимо. Поделят на классы, или квалификации, или грейды, и оклады поменяют.


    – Бородатый, тащи свою жопу сюда! Щас тебя грейдить будем! Будешь из класса Паладинов – полупрограммист, полужиголо!


    – Колян, хорош, давай серьезно! – Сергею было явно не до шуток. – Тут твои колхозные методы поиска лазеек не прокатят. Чувак серьезный.


    – Чувак-то серьезный, только он из Москвы.


    – И что?


    – А мы – из Тагила.


    – Не вижу связи.


    – Много ты чуваков московских видел, которые в Тагиле зависают? Горящие путевки в Тагил где продают? Прямо в Шереметьево? Отбоя нет от желающих?


    – Ты к чему клонишь? – чувствуя, что Колян уже знает решение, но боясь до конца в это поверить, спросил Сергей.


    – К тому, что этот парень напишет тебе требования по… как их…


    – Грейдам.


    – Да, грейдам, и укатит. На это его контракт закончится, я уверен. Не будет же он тут сидеть и ждать результатов?


    – Ну, допустим… Хотя нет, а почему не будет? Он же консультант.


    – Много ты видел консультантов, которые НА РЕЗУЛЬТАТ подписываются?


    – Да я вообще консультантов немного видел. – глядя в потолок пробормотал Сергей.


    – Ну вот те засранцы 1Сники, которые до нас тут Битрикс поставили, и сказали, что это – ERP-система, а потом свалили и трубку не берут теперь – консультанты? – весело спросил Колян.


    – Вроде да, так на сайте написано у них. Еще потом внедренное решение опубликовали, типа они для нас консалтерский проект выполнили. Я еще помогал юристам письмо составить, с требованием об удалении нашего названия из этого внедренного решения.


    – Ну, а здесь почему будет иначе? Те, битриксоиды, тоже ведь из Москвы были?


    – Ладно, я понял. Свалит он. Дальше что?


    – А ничего. Немножко провалимся опять, через месяц-другой догоним. Ты видел бумажки эти? Ну, с требованиями.


    – Он сказал, что еще не закончил, но кой-чего дал.


    – Так, что тут у нас… Постоянное расширение компетенций в используемых и новых фреймворках… Использование коммуникативных навыков… Ответственность за потоки работ…


    – Это ты чего читаешь? – удивился Сергей. – Там вроде меньше было текста.


    – Самый дорогой грейд, чего же еще. Стрелять, так стрелять. – пропел свой любимый хит (или шлягер) Колян.


    – Вот бы мне твой оптимизм…


    – Учись, пока я жив. – с наигранным превосходством сказал Колян.


    – Ладно, О Великий Учитель, что скажешь про грейды?


    – Халява, проще чем с проектами. Вот смотри. Постоянное расширение компетенций… Так… В используемых фреймворках… О, не только в используемых, но и в новых!


    – И чего, новые фреймворки будем изучать?


    – Почему бы и нет? Я всегда хотел Angular раскурить. Вот и момент настал. Боже, мне за это еще и заплатят!


    – Колян, ты говна поел? Какой Angular? У нас на react’е все крутится. Ты же мне все время про красоту react’а рассказываешь, а тут…


    – Э, ты не путай разговор про технологии и про зарплату. Если для получения премии надо раскурить Angular, раскурим Angular. Черт побери, я даже найду и скачаю Delphi и сделаю тебе СУБД на Paradox 7, с отчетами на Fast Report. Или, прости Господи, за 1С засяду.


    – А, вон ты про что… И как мы совместим react и angular в одном приложении?


    – Хорошая, интересная, инженерная задача. Кстати, ее тоже можно впарить под соусом изучения новых фреймворков.


    – Ладно, я понял тебя. Обсудим, когда чувак смоется в Москву, чтоб вопросов лишних не было. С остальным что?


    – Ну тут вообще халява. Коммуникативные навыки, ответственность… Сколько у нас сейчас проектов в работе? Тех, которые еще со старой системы мотивации остались?


    – Щас… Восемь вроде.


    – Ну все. Три тебе, три мне, два Бородатому.


    – В смысле? Что это значит?


    – Ну ты тупой, а… Руководство проектами делегируй! Я буду руководить тремя проектами, Бородатому – два с лихвой, а тебе, красава наша, три самых вкусных отдадим.


    – А в чем смысл-то? Мы итак эти проекты делаем, никто уже с нами связываться не хочет, «на ура» подписывают и требования, и акты.


    – Смысл – в формальном руководстве проектом, суть которого – ответственность и коммуникации. Один в один – требования высшего грейда. Сразу станем высшими эльфами, без скакания по горам для развития Акробатики.


    – И кто поверит, что Бородатый может руководить проектом?


    – Хм…


    – Э, вы чего, я вам лошара что ли какая-то? – возмутился Стас. – Отправьте меня на курсы, да и все.


    – Какие тебе курсы нахрен… – задумчиво проговорил Колян. – А стой, это же идея! Серега, давай, садись, ищи!


    – Чего искать?


    – Блин, самые лоховские курсы по управлению проектами! Чтобы быстро, недорого и с какой-нибудь корочкой!


    – Так не дадут же.


    – Чего не дадут-то, ты положение забыл что ли? Начальник отдела может отправить на обучение любого сотрудника, с оплатой в пределах 10 т.р. – без согласования! Мы Петровича так на базу отдыха отправляли, их сисадминская тусовка это как курсы оформила.


    – Ладно, я попробую… Блин, даже не знаю, с чего начать. В ВУЗах что ли посмотреть?


    – Да какие ВУЗы, там по полгода мозги мурыжат! О, давай в 1Сных конторах посмотрим? Помнишь, эти вафлы нам свои сертификаты показывали, какие-то желтые, там было написано, что они все – руководители проекта.


    – Ну да вроде… Блин, ты серьезно? У 1Сников учиться руководству проектами?


    – Да я хоть у хабологов научусь, если быстро и в грейд. Ты давай это, понты свои Бауманские забудь, тут реальная жизнь. Все, расходимся по-одному. Ищи курсы, держи нос по ветру, посматривай за чуваком. Петрович поможет.


    – Ладно, понял.


    А вы это время в кабинете директора


    – Анатолий Викторович, все уже давно придумано. Все системы мотивации, которые вы внедряли, имеют один существенный недостаток – они не из IT. Это – классическая попытка натянуть сову на глобус.


    – Сову на глобус? – лениво поинтересовался Анатолий Викторович.


    – Выражение такое есть, про использование неподходящих теоретических моделей для решения практических задач.


    – А, понял. Ладно, Борис, давайте к делу. О каком решении вы говорите?


    – Решение простое – ITIL. Это методика организации ИТ-служб. Там все написано, посчитано, автоматизировано. Просто берете и пользуетесь.


    – Знаете, Борис, вы уже пятый, кто мне это говорит. – Анатолий Викторович не пытался скрыть своего скептицизма.


    – Но я – первый, кто не «как-то там связан с ИТ», или «когда-то работал с ИТ». Я – человек из ИТ. И я знаю, как измерять труд программистов.


    – Хорошо, я понял. Давайте суть.


    – Суть – метрики. Измерение или результата работы, или отсутствия проблем. Если проблем нет и результат хорош – получаешь свою зарплату. Если простояла система полдня – извини, дружок, надо было принимать меры до наступления кризиса.


    – Про простои понятно, можно обсудить. А работу измерять как?


    – Классические метрики ITIL – это… Так, сейчас… Где это… А вот! Вам больше всего подойдет: количество закрытых проблем со статусом «решена», «количество нарядов», или даже «количество завершенных нарядов». Наряды – это вроде задач. «Количество изменений» еще можно… «Количество релизов».


    – Борис, я прошу прощения, у меня срочный звонок. – Анатолий Викторович залез в карман, видимо за телефоном. Руку из кармана не доставал. Звука и вибрации, почему-то, слышно не было. – Вы не могли бы подождать нас в другой переговорной? Света вас проводит.


    – Да, не вопрос, я все понимаю!


    – Понимает он… – злобно сказал Анатолий Викторович, когда Борис вышел. – Тань, я не могу больше. Мы опять идем по кругу. Что он там мелет? Количество нарядов?


    – Да, вроде так. Еще что-то про количество проблем и релизов.


    – Ну это уже ни в какие ворота. – голос Анатолия Викторовича снова становился усталым. – Мы уже платили за строки кода, за задачи, за проекты, за хрен пойми что. А этот, прошу прошения, хер с горы нам рассказывает про какие-то метрики, которые суть – то же самое.


    – Да, я тоже заметила некоторое сходство. – спокойно проговорила Татьяна Владимировна. – Не хотела вслух сомнения высказывать, вы мне Бориса не успели заранее представить. Он тоже с EMBA?


    – Да какое там… Хотя, какая разница… Был тут один с EMBA. – устало засмеялся Анатолий Викторович. – Этого друг посоветовал, говорит – толковый парень, чего-то ему внедрял на заводе.


    – Хотите с ним поработать?


    – Нет, уже не хочу. Ни с кем не хочу.


    – Ну это эмоции, Анатолий Викторович. Не поддавайтесь им, вы же знаете, это губительно. Просто возьмите паузу, решение придет само.


    – Хорошая идея… Паузу взять… Да, давай паузу! На все выходные – на базу отдыха, на озерцо, чтоб баня и рыбалка!


    – Ммм, звучит заманчиво…


    – Поедешь?


    – Нет, увы, планов много.


    – Так, а я с кем поеду? С женой что ли? Нет, она на Кипре до конца месяца.


    – Ну не знаю… Может, кого из сотрудников? Для тимбилдинга? Продавцов, как в прошлый раз?


    – Нееее, слушай! Программистов! Давай программистов!


    – Точно? Вы с ними никогда особо не общались.


    – Серьезно? Мне кажется, я их как облупленных знаю, все секреты их профессии. Да, неважно… Давай программистов.


    – Окей, сейчас схожу к Сергею. Не уверена, что все поедут – они, наверняка, интроверты.


    – Сделай, чтобы поехали, Тань. Пожалуйста.


    – Я постараюсь, Анатолий Викторович.

    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 153
    • –18
      Где-то к середине статьи уже становится понятно, что директор изначально выбрал не ту стратегию управления персоналом. Он увольнял кадровиков и менял системы мотивации программистов. А надо было сразу увольнять тех программистов. В принципе, после первого же случая, когда они стали счетчики денег накручивать ценой ухудшения качества софта.
      • +20
        А у вас программисты работают не за деньги, а за результат и копроративные ценности?
        • –3
          За деньги. Но в вышеуказанной статье персонажи ведь не работали, а сугубо решали вопрос, как систему обмануть. А это уже, скажем так, находится где-то в той же области, что и воровать на работе.
          Да тут и думать нечего, херачим по полной. Никакой оптимизации, повторного использования кода, абстракций и прочей ереси.

          Это ведь саботаж, разве я неправ?
          В нормальной ситуации программист идет к директору вместе с эйчаром и говорит, почему такая система мотивации тупая. А не начинает саботировать.
          • +9
            говорит, почему такая система мотивации тупая.

            Я говорил с новой ХаРэ, ей пофиг, выслужиться хочет.
            • +18
              Мне кажется, это ожидаемая форма «бунта» против насильно навязанной системы оплаты труда. Итальянская забастовка, если хотите.
              • +3

                Все зависит от оплаты. Если опытному программисту за малое кол-во строк кода начнут платить как новичку (ну ведь мало же строк), то это уже кидалово со стороны руководства


                Ну а что до разговора программистов и руководства — да, очевидно нужно говорить, но тут в том и смысл что руководство не хотело вникать в особенности работы, оно хотело получить готовое решение

                • +1
                  Судя по тому, что руководство оценивало всё что угодно, но только не результат, им было на самом деле плевать на готовность решения.
                  • +1

                    Руководство хотело привязать оплату труда программистов к чему-то (при этом в идеале еще и чтобы платить меньше, если бы все утраивало — тогда и не лезли бы дальше), но оно не хотело думать само, а надеялось что придет волшебник и сделает все как надо

                • +3
                  Бизнес это не клуб друзяшек. Начальник должен понимать что если он поставит работника в положение при котором для него будет рациональнее работать плохо — вероятнее всего именно так он и поступит. И тут дело не в том что он плохой человек, а в том что для него создали такие условия.

                  А насчет «пусть подходит и говорит почему система тупая» — да, конечно, отлично, потом пусть ещё к бухгалтерам зайдет и объяснит как правильно деньги считать, потом уборщице расскажет как правильно пол мыть, потом ещё охране устроит ликбез по самообороне. А то они ведь все глупенькие и неразумненькие, им объяснять надо как им их работу делать.
                  • 0
                    Да, но с другой стороны, это и не психбольница, где каждый ведёт себя так, как у него настроение сложилось, и надо прятать острые предметы от тех, у кого оно плохое. Представьте себе, что вы приехали на автосервис, а механик в вашей машине болты молотком забивает. И говорит вам, что у него мотивация на количество выполненных работ завязана, вот он и делает, чтоб побольше успеть. Это ведь абсолютно то же самое, что и в примере в статье. Да, мотивация тупая. Но ведь и специалисты — не дрессированные медведи, а взрослые, отдающие ответ в своих действиях люди. Причем речь идет даже не о рабочих, у которых в голове всё, что угодно может быть, а о квалифицированных специалистах. Есть какие-то профессиональные рамки, как у автослесаря, так и у программиста. За них нельзя заходить. Если обстоятельства вынуждают — иди, договаривайся. Если не получилось договориться, прощайся с конторой, благо, программист без работы не останется, а адекватных мест навалом. Вредить-то зачем? Это последнее дело.
                    • 0
                      Есть какие-то профессиональные рамки, как у автослесаря, так и у программиста. За них нельзя заходить.

                      А у дурака-директора в это примере есть?
                      Если у него цель была развести работников как лохов и платить им меньше повесив на них чувство вины, то он — сам себе злобный Буратино.
                      • +1
                        Во-первых, директор, если это не директор ИТ-компании, не дурак. Это не его компетенция, придумывать системы мотивации. Его задача выслушать экспертов и принять решение. В данном случае ему с «экспертами» не повезло. Там просто должен был быть начальник ИТ-департамента вместо эйчара.
                        Во-вторых, мы все отвечаем за собственные поступки, и не отвечаем за поступки других. Если чувак в соседнем отделе, например, ворует из общего холодильника продукты, это не оправдывает вас, если вы тоже будете их воровать, верно? Так почему профессиональная некомпетентность кого-то из руководителей должна оправдывать саботаж кого-то из подчинённых?
                        • +1
                          Так почему профессиональная некомпетентность кого-то из руководителей должна оправдывать саботаж кого-то из подчинённых?

                          Потому что в данной истории эта некомпетентность напрямую отражается на их зарплате. Попытка объяснить закончилась результатом "ей пофиг". Они по-вашему должны были согласиться за ту же работу получать зарплату меньше?

                          • +1
                            Но ведь в данной истории ничего про «зарплату меньше» не сказано, зато вполне определённо указано, что по такой схеме их зарплата наоборот, увеличилась в два раза, а с директором они вообще не разговаривали, просто с энтузиазмом воспользовались возникшей «брешью» в системе мотивации, причем с катастрофическим снижением качества продукта. Разве не так?
                            • 0
                              А смысл в такой ситуации разговаривать с директором?
                              Тут в комментарии habr.com/post/401355/#comment_18709019 уже разъяснили — разговаривать в такой ситуации с директором это напрашиваться на увольнение с «волчьим билетом».
                              • +1
                                разговаривать в такой ситуации с директором это напрашиваться на увольнение с «волчьим билетом».

                                Почему? Если, конечно, начинать про творческую работу вещать, то директор пошлёт лесом (без всяких увольнений, конечно же). Но если просто взять и объяснить, почему мотивация по строчкам кода — глупость, практически любой директор выслушает и попросит предложить что-то адекватное.
                                У вас в воображении директора какие-то монстры, причем недалекого склада ума. А это не так. Они во-первых обычные люди, во-вторых, по профессии управленцы. А это значит, что выслушивать, давать оценку предложениям и принимать решение — это их обычная работа.
                                • 0
                                  Давайте все таки рассматривать ситуацию в контексте. Контекст — это то, что окружает ситуацию. Да, идет гипербола о директоре-монстре, который слушает одних и не слушает других.
                                  Попробуем тогда сменить контекст. Представим директора, который вырос из программистов и сохранил живость ума и интерес к этому. Его правая рука — программист, творящий гениальные вещи в бизнес-моделях, левая рука — программист, который собаку сьел на нейронных сетях и системах непрямой логики. И вся верхушка такая же. Эта компания решает организовать отдел продаж, для чего нанимают специалистов-продажников во главе с неплохим начальником. И естественно пытаются покрыть их работу системами автоматизации.
                                  Через какое то время это руководство обнаруживает, что продажники заняты обычным для них делом — вместе с поиском покупателей/продавцов нужных вещей обстряпывают собственные делишки, умело задерживают договора в стадии подвиса, чтобы договор не ушел без «интереса» — отката в пользу продажника, растягивают или концетрируют платежи, чтобы получить максимальную премию за договор, и так далее.
                                  Директор-программист понимает это и организовывает контрмеры — блокировку левых аккаунтов, предупреждение контрагентов по факту о прекращении откатов, и так далее. Без увольнений. только контроль и профилактика.
                                  И вот к директору придет начальник продажников и начнет рассказывать, просто брать и объяснять, почему мотивация по чистоте сделок и минимуму откатов — глупость, что людям нужно дать проявить творчество в работе, что воровать естественно и непостыдно… Его не поймут. Директор-программист не поймет вора, точно так же как директор-вор не поймет программиста, разные вообще представления о процессе и доверии.
                                  Программист не может доверять вору — он не может уложить в уме что воровать это нормально, а вор не может доверять программисту — у него в уме не может уложиться что человек может преследовать не личные, а общие интересы.
                                  И там и там нет монстров. Там просто разные уклады ума, и если человек вырос из IT-он сам все поймет что надо, если же он как обычно закончил Высшую школу менеджемента — он поймет только что ему втирают какую то дичь, которую вот щас директор по персоналу объяснит четко и внятно, что это за фигня и подстава.
                              • +1
                                по такой схеме их зарплата наоборот, увеличилась в два раза

                                Ну так им же поставили цель — вы должны работать хорошо, а для этого от вас нужно больше кода.
                                Уменьшение зарплаты это логичное следствие написания переиспользуемого кода. В этом месяце написали 1000 строк новых функций, в следующем вызываем с нужными параметрами одной строкой из сотни мест. Разница в 10 раз.


                                а с директором они вообще не разговаривали

                                "Вот этими сказками я уже сыт по горло"
                                "Инженеры-конструкторы тоже постоянно на творчество ссылаются"
                                "Действуйте!"


                                Судя по этим фразам, ему об этом говорили, в том числе и директор Татьяна Владимировна. И ему это не понравилось.
                                Он предоставил полномочия новой HR, поэтому программисты разговаривали с ней. Вполне могло быть и так, что когда программисты к нему пришли, он сам отправил их с фразой "Этим вопросом занимается специалист, разговаривайте с ней".


                                причем с катастрофическим снижением качества продукта.

                                О каком снижении качества вы говорите? Что так кардинально изменится, если добавить папку "vendor" в репозиторий?
                                Копи-паста тоже не снижает качество продукта в момент копирования, он работает как работал, она просто увеличивает сложность поддержки. Снижается качество кода, как текстовой модели предметной области. Но с учетом количества кода в зависимостях ее даже применять необязательно.

                                • 0
                                  О каком снижении качества вы говорите?

                                  Там черным по белому написано:
                                  Да тут и думать нечего, херачим по полной. Никакой оптимизации, повторного использования кода, абстракций и прочей ереси.


                                  «Вот этими сказками я уже сыт по горло»
                                  «Инженеры-конструкторы тоже постоянно на творчество ссылаются»

                                  Ну а что тут не так? Это же не гейм-дизайнеры были. Творческая составляющая в работе программиста бизнес-приложений — это где-то 3-5% его работы. В основном как кнопочки расставить, и какой цвет меню выбрать. Что творческого в том, чтобы сделать таблицу БД по заданному списку полей, сделать под неё модель, форму и настроить биндинги/валидацию/авторизацию?
                                  Чем-чем, а творчеством тут можно смело пренебречь.
                                  • 0
                                    Там черным по белому написано

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


                                    Творческая составляющая в работе программиста бизнес-приложений — это где-то 3-5% его работы.

                                    "Творческий" здесь антоним формального и абсолютного. Это не совсем правильный термин, но для противопоставления этого достаточно. Три строки кода это много или мало? Когда-то много, когда-то мало, зависит от контекста. Под творчеством понимается способность человека анализировать ситуацию и давать оценку — много/мало, правильно/неправильно.

                                    • 0

                                      В этом проблема всех формальных метрик. Потому что они не формальные, а контекстно-зависимые. Это будет работать если контекст всегда и у всех одинаковый.
                                      Поэтому нельзя сделать программу, которая по метрикам будет правильно анализировать работу программистов (и других аналогичных профессий). Замкнутый круг — для анализа метрик надо анализировать контекст, а как его анализировать, другие метрики вводить? Выход только в создании ИИ, аналогичного по возможностям ЕИ, который сможет структурировать и анализировать произвольную информацию.

                                      • 0
                                        Ну так это решение они приняли после разговора.

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

                                        Очень сложно найти работу, в которой всё формально и абсолютно. По сути, это лишь повременная работа вроде сторожа. Все остальные такие же, пусть будет творческие.
                                        Вот, например, работа сантехника творческая? Как правило, все считают, что нет. Даже сантехники. Но я вот недавно менял радиатор отопления, сантехники сначала мне предложили интерфейс, вот тут разместить вентили, чтобы было удобно перекрывать, а вот тут сделать байпас. Потом во время работы у них одна гайка разломилась, кусок остался в радиаторе, пришлось по ходу дела костыль разрабатывать — надпилить её изнутри, вставить туда зубило и газовым ключом его провернуть. И знаете что? Всё эти решения ничем принципиально не отличаются от тех, которые в своей работе принимает программист. И нормируется работа сантехника ничуть не точнее, чем работа программиста. Вы просто исходя из опыта оцениваете, сколько времени и других ресурсов потребуется на реализацию поставленной задачи (решение которой вам изначально вполне понятно, если только вы не работаете над каким-то редким наукоёмким проектом), накидываете проценты на риски, и считаете её стоимость.
                                        • 0
                                          А оценивать зарплату по количеству строк кода не подлость?!
                                          Можно затратить целую неделю чтобы найти баг (ошибку), а затем написать меньше одной строчки кода для исправления этого бага, как итог недельных трудов!
                                          • 0
                                            А оценивать зарплату по количеству строк кода не подлость?!

                                            Нет, не подлость. Это некомпетентность того, кто придумал систему мотивации. Но даже если бы и подлость, то что? Васе навредило руководство, Вася навредил своим пользователям. Это означает справедливость? Нет, это означает, что Вася — такое же говно, как и его босс.
                                            • 0
                                              Неправда.
                                              Васе навредило руководство — нет же, зарплата у Васи сохранилась.
                                              Вася навредил своим пользователям — тоже нет, пользователи получили свой товар.
                                              А если есть подозрения, что товар у Васи получается не того качества — так можно же придумать метрики для измерения качества… Oh, shee…
                                              • 0
                                                А если есть подозрения, что товар у Васи получается не того качества

                                                Качество товара — это такое же обязательство, как и сама поставка товара.
                                                • 0
                                                  И снова здрасьте.
                                                  Факт поставки (непоставки) товара легко проверяется. Согласно акту выполненных работ Вася написал программу. Программа ТЗ соответствует.
                                                  А вот есть ли связь между качеством Васиной программы и попытками Васи накрутить себе счетчик… Разве что вместо разработки лайфхаков Вася мог бы делать что-то полезное и получать за это деньги… Но ведь ему платят не за полезную деятельность, а за ее имитацию.
                                                  • 0
                                                    Факт поставки (непоставки) товара легко проверяется

                                                    Ну вот поставили вам китайские игрушки, по накладной товар поставлен. А у них краска слезает через месяц, или съедается ребенком.
                                                    Приняли вы программу, которая соответствует ТЗ, подписали акты. А в процессе эксплуатации выяснилось, что через через час работы на реальных данных валится с out of memory, надо перезапускать, а через месяц после накопления данных формы стали по пять минут открываться.
                                                    Какой из этих (самых обычных, и часто встречающихся, между прочим) вариантов легко проверяется на этапе приемки?
                                                    • 0
                                                      Нагрузочным тестированием? Это лишь означает что ТЗ составлено недостаточно подробно.
                                                      • 0
                                                        через через час работы на реальных данных валится с out of memory

                                                        через месяц после накопления данных формы стали по пять минут открываться


                                                        Заказчик не слышал про тестирование. Жаль.
                                                        Но какая, чорт возьми, связь утечек памяти в программе и стиля написания программы?
                                                        • +1
                                                          Заказчик не слышал про тестирование. Жаль.

                                                          Допустим, слышал. Но я вот, например, ничего не слышал про существование в природе методик тестирования, которые позволяют за приемлемые затраты получить гарантированный результат качества. Минимизация проблем обеспечивается в первую очередь культурой разработки, а не тестированием.
                                                          Но какая, чорт возьми, связь утечек памяти в программе и стиля написания программы?

                                                          Хм. Ну даже и не знаю, как вам объяснить. Какая связь между ездой с нарушениями правил и аварийностью? Вот примерно такая же.
                                                          • 0
                                                            Какая связь между ездой с нарушениями правил и аварийностью? Вот примерно такая же.


                                                            То есть связь проследить сложно.
                                                            Езда без водительского удостоверения — это нарушение правил, да. И с непристегнутым ремнем, да. И без страховки, да. Означает ли это, что если удостоверение оставил дома, это как-то повлияет на аварийность?
                                                            В некоторых странах недопусимо употреблять алкоголь за рулем совсем. В некоторых — допускается некоторый уровень алкоголя, до 1-2 бутылок пива. И аварийность у них почему-то не выше.
                                                            Связь между копипастой кода (и другими способами просто увеличить количество строк) и утечками памяти такая же.

                                                            Минимизация проблем обеспечивается в первую очередь культурой разработки, а не тестированием.

                                                            Возражений не имею ;)
                                                            Если где-то платят за культуру разработки и умеют уровень этой самой культуры адекватно измерять… Рад за них ;) У придуманных героев рассказа другие ценности.
                                                            • 0
                                                              То есть связь проследить сложно.

                                                              Главное в том, что она однозначно есть, и достаточно заметная :)
                                                              • 0
                                                                Главное в том, что она однозначно есть, и достаточно заметная :)


                                                                О вреде огурцов? :)
                                            • +1
                                              Ну и тем не менее, это профессиональная подлость.

                                              В чем именно вы видите подлость? Не общими словами, а конкретно на примерах — до изменений было то-то, после изменений стало то-то. Я вот не вижу ничего, что можно описать этим словом. Для пользователей ничего не изменилось, для программистов изменилось то, что они сами захотели.


                                              Тем более что в статье написано, что они зарплату этим удвоили, а не просто сохранили.

                                              Ну так от них же требовали работать лучше. Да еще и каждый месяц нормы удваивали.


                                              Не нравится работа — меняй, а не вреди.

                                              Убегать из-за каждой неприятности? Ее может уволят через 3 месяца, зачем из-за этого работу бросать.
                                              И да, никто никому не вредил. Продукт продолжал выполнять свои функции. Ну отложили рефакторинг на неопределенное время. Думаете в других местах плохого кода не бывает?


                                              Вот, например, работа сантехника творческая?

                                              У сантехника критерии соответствия результата задаче более простые, и видов задач гораздо меньше. Написано "установить одну батарею", значит в результате нужна одна работающая батарея, входы-выходы стандартизированы, требуемые детали стандартизированы.
                                              Вот если бы программистам ставили задачи "установить библитеку jQuery", и они бы их пачками устанавливали в разные приложения, тогда да, творчества (анализа) тут мало.
                                              А если бы некие сантехники придумывали способы, как подвести воду к нестандартному объекту в нестандартной местности, то это были бы уже инженеры, и работа такая более творческая.

                                              • +2
                                                Если бы сантехникам платили только установленные батареи, и не платили бы ничего за устранённые течи, то они тоже прекратили бы устранять течи.
                                                • 0
                                                  Ситуация тут как раз наоборот. Сантехнику, в отличие от программиста, заплатят только за идеально установленную батарею. Ему не будут платить за слегка подтекающую батарею, за батарею, которая плохо греет из-за завоздушивания, а криво повешенную, но при этом выполняющую на сто процентов свой основной функционал батарею сантехника вообще заставят бесплатно заново перевешивать :)
                                                  Так что не сравнивайте так, пожалуйста. Программист — это едва ли не единственная профессия, где нормой считается делать кое-как, лишь бы работало.
                                                  • 0
                                                    Если сантехника запрячь батарею вешать за пять минут, тоже будет криво.
                                                    • 0
                                                      И в этом плане сантехник тоже от программиста не отличается :)
                                                      • 0
                                                        Да, получается, что основное, чем отличается — это тем, что сантехников, в массе своей, не просят делать все вдвое быстрее, чем надо, в отличие от программистов. А все остальное — и формальный/творческий подход к работе, и способ получения необходимых навыков, и тд — все очень похоже.
                                                        • 0
                                                          Нет, сантехников тоже просят сделать быстрее, чем надо. И они делают. Поверьте, ситуация, когда дома трубу прорвало — она в системе ценностей юзера находится намного выше ситуации, когда у него на работе платежки перестали сохраняться.
                                                          Разница в том, что спрос на услуги сантехников ниже, чем на услуги программистов. Поэтому сантехники вынуждены конкурировать друг с другом, и скоростью, и качеством. А программистам это не обязательно.
                                                          • 0
                                                            Причина разницы в том, что стать сантехником легче, чем вайти-в-айти.
                                                            • 0
                                                              Честно говоря, ни разу не слышал, чтобы сантехнику говорили «делай пофиг как, главное, чтобы через пять минут было готово» — максимум это будет «делай хорошо, но постарайся побыстрее». И если бы первая ситуация и правда имела место, я не могу себе представить сантехника, отвечающего «нет, я буду делать дольше, но лучше».
                                                              • 0
                                                                «делай пофиг как, главное, чтобы через пять минут было готово»

                                                                А разве программистам так говорят конечные пользователи? Это начальник ИТ может так сказать, или продаван.
                                                                • 0
                                                                  Бывает, что говорят. Ну и менеджер или продажник — они являются прокси к заказчику, почему бы программисту им не верить?
                                                                  • 0
                                                                    Говорят. Ещё как говорят. Иногда даже истерики устраивают. Буд-то для решения их хотелко-проблемы надо не пол системы переписать, а где-то на одну кнопку нажать.
                                                    • 0
                                                      Не общими словами, а конкретно на примерах

                                                      Конкретно на примерах, обсуждая изначально выдуманный кейс, это сложно :). Но фраза «никакой оптимизации, повторного использования кода» и т.д. на практике практически всегда приводит к тому, что продукт начинает работать плохо, баги кочуют из одного участка программы в другой (код-то дублируется, а не вызывается из общей библиотеки/класса/сервиса) и т.д. Уж кто-то, а мы все прекрасно знаем, как подобный подход ухудшает качество работы пользователей. Другое дело, что многие программисты занимают позицию «задачу выполняет? Ну и достаточно, чего вы ноете, что тормозит/глючит? Подождите, перезапустите, и работайте дальше». При этом, конечно, недовольны, если то же самое вытворяет, например, Eclipse, или, чур меня тьфу-тьфу-тьфу, Atom.
                                                      Убегать из-за каждой неприятности? Ее может уволят через 3 месяца, зачем из-за этого работу бросать.

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

                                                      Вы знаете, об этом можно спорить бесконечно. Да, наверное, в какой-то мере проще. Но принципиально никаких отличий нет. Вы можете установить одну батарею, вроде как всё просто, но вы должны ещё предложить варианты этих батарей пользователю, определить её мощность, учитывая целесообразность, допустимые размеры и кошелек пользователя. Делать ли за батареей отражатель? А какие крепления под батарею, и сколько их? Даже в такой простой задаче есть масса вариантов.
                                                      А позовите этого же сантехника класть вам тёплый пол, например, там уже и нехитрая инженерия добавляется, ведь нужно рассчитывать плотность укладки и температуру теплоносителя, исходя из площади помещения, характеристик стен, остекления и т.д.
                                                      Написано «установить одну батарею», значит в результате нужна одна работающая батарея, входы-выходы стандартизированы, требуемые детали стандартизированы.

                                                      Ну так и у программиста бизнес-приложений в общем случае то же самое. В чём может проявляться творчество в работе «сделать печатную форму» или там «добавить вот такой-то документ с таким-то бизнес-процессом прохождения»? Как расставить поля на форме или как назвать поле в базе данных? Это примерно то же самое, что и «вам вентиль тут повесить, или на 10 см в сторону». У программиста же там нет пространства для придумывания чего-либо, вся эта работа делается также по типовому шаблону.
                                                      • 0
                                                        за батарею, которая плохо греет из-за завоздушивания, а криво повешенную вообще заставят бесплатно заново перевешивать

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


                                                        где нормой считается делать кое-как, лишь бы работало.

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


                                                        Другое дело, что многие программисты занимают позицию «задачу выполняет? Ну и достаточно, чего вы ноете, что тормозит/глючит? Подождите, перезапустите, и работайте дальше»

                                                        Ни разу не слышал, чтобы кто-то так говорил в отношении своего проекта. В крайнем случае между собой решат, что это не приоритетный баг.


                                                        Ведь вроде как речь о том, что начальство не слушает программистов.

                                                        Речь о том, почему они начали писать длинный код. Я считаю, что у них были обоснованные причины.


                                                        ведь нужно рассчитывать плотность укладки и температуру теплоносителя

                                                        Ну так и задачи такие оцениваются индивидуально, исходя из контекста, а не из количества закрученных болтов.


                                                        В чём может проявляться творчество в работе «сделать печатную форму» или там «добавить вот такой-то документ с таким-то бизнес-процессом прохождения»?

                                                        Вот если бы печатные формы продавались готовые, то сравнение было бы уместно. А ее надо придумать, бизнес-логику процесса написать, да потом еще и изменения вносить. Часто ли сантехники новые конструкции батарей изобретают?
                                                        И как я сказал, под творчеством имеется в виду анализ контекста. Выбор между кучей возможных способов сделать одно и то же. Любые ли 1000 строк для генерации формы должны оцениваться одинаково? А 900 это лучше или хуже?

                                                        • 0
                                                          Ну так и задачи такие оцениваются индивидуально, исходя из контекста, а не из количества закрученных болтов.

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

                                                          Да не надо там ничего придумывать. Форма, минуточку, это пачка из списка полей и CRUD-операции над ней. Всё придумывание — это дать им название и расставить по порядку. Это сугубо механическая работа. Точно так же механически цепляются правила валидации.
                                                          Выбор между кучей возможных способов сделать одно и то же.

                                                          Давайте честно, эта дилемма стоит перед программистом один раз. Тогда, когда он учится использовать платформу. Если вы не учитесь, а работаете, у вас есть тот способ, который вы выбрали — например, вы с базой можете работать или через какой-то набор адаптеров SQL, или через ваш любимый ORM. И вы ваш любимый метод будете использовать всегда, а не плодить в своём коде зоопарк из разных подходов. Если вы дописываете существующее приложение, у вас вообще количество вариантов ограничено одним, не зависящим от ваших предпочтений. Тем, который выбрала в своё время команда разработки или архитектор.
                                                          • 0
                                                            всячески его поддерживает в своих интересах в ущерб качеству работы

                                                            Ну то есть, по-вашему они должны были продолжать писать переиспользуемый код ради высших целей и получить во второй месяц 1/10 зарплаты? Ведь как мы выяснили, договориться об отмене у них не получилось.
                                                            Я бы вот не согласился на уменьшение зарплаты, а попытался бы показать на примере несостоятельность метода, раз словами объяснить не получилось. Можно считать это уважением к другим программистам, ведь если просто уволиться, наймут новых работников и продолжат применять эту систему.


                                                            Всё придумывание — это дать им название и расставить по порядку.

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


                                                            Давайте честно, эта дилемма стоит перед программистом один раз.

                                                            Она стоит перед ним каждый раз, когда он придумывает имя переменной. Можно ведь однобуквенными переменными нафигачить, на методы не разбивать, значения хардкодить. Я это имел в виду, а не архитектуру приложения.

                                                            • 0
                                                              Ну то есть, по-вашему они должны были продолжать писать переиспользуемый код ради высших целей и получить во второй месяц 1/10 зарплаты?

                                                              По-моему, их начальник должен был пойти и сказать, что это полная хрень, и объяснить, почему. Без слов «творчество» и «невозможно оценить» (потому что да, все руководители за этими словами в устах инженера ничего кроме «я так и не научился оценивать собственный труд» не видят). А со словами «смотрите, эту задачу можно сделать быстро вот так и долго вот так, и в этом случае получится в два раза больше кода. Вы действительно хотите замотивировать программистов делать больше?» И директор ему бы гарантированно сказал: «Упс, да, это не сработает. Какие тогда есть предложения?»
                                                              Она стоит перед ним каждый раз, когда он придумывает имя переменной.

                                                              Я не согласен. Вы-то всё это сделать можете, но ведь никогда не будете. Сантехник тоже имеет возможность выпендриться, и пустить холодную воду петлёй через кладовку. Но он так делать не будет. Также и программист не будет упражняться в придумывании нестандартных схем, а сделает так, как это принято по гайдлайну (или при его отсутствии — по best practices) разработки на его платформе. Переменные все именуются механически. Переменные-индексы i,j,k. Переменная для хранения суммы — Amount. Поле для хранения суммы в классе С++ — m_amount :)
                                                              Переменная для хранения веса — Weight, переменная для хранения средней зарплаты — AverageSalary, и так далее. Нет там ничего неформализуемого.
                                                              • 0
                                                                По-моему, их начальник должен был пойти и сказать

                                                                Так ходили же. Про "творчество" до этого было, от других людей. Они ходили к HR, и ей пофиг.


                                                                А со словами «смотрите, эту задачу можно сделать быстро вот так и долго вот так»
                                                                И директор ему бы гарантированно сказал: «Упс, да, это не сработает. Какие тогда есть предложения?»

                                                                "А откуда я знаю, я же в этом не разбираюсь. Вам лишь бы не работать."
                                                                Если бы директор хотел узнать предложения программистов, он бы сразу их спросил.


                                                                Также и программист не будет упражняться в придумывании нестандартных схем

                                                                Причем здесь нестандартные схемы. Я говорю про варианты стандартных схем. Вы же не будете утверждать, что по описаниию бизнес-задачи можно определить единственный вариант исходного кода, который ее решает?
                                                                Даже с формой не все так просто, понадобился там сложный datepicker с диапазоном — какую библиотеку выбрать, использовать библиотечный вызов с длиннющим конфигом или в обертку вынести, сложный валидатор отдельным классом сделать или заинлайнить так как он больше нигде понадобится...


                                                                Нет там ничего неформализуемого.

                                                                Ну и как вы формально проверите, что в этом месте обосновано имя переменной n, а в другом нет?
                                                                Как определить, что вот этот кусок кода лучше в метод вынести?
                                                                Если бы можно было это автоматизировать, давно бы сделали. Но пока требуется участие человека.

                                                                • 0
                                                                  Вы же не будете утверждать, что по описаниию бизнес-задачи можно определить единственный вариант исходного кода, который ее решает?

                                                                  Не буду, но буду утверждать, что из равнозначных вариантов, подходящих для решения, есть всегда какой-то один, который программист выберет без колебаний, и сколь-нибудь существенное время на выбор варианта реализации он тратить не будет. Разве у вас сходу нет готового ответа на все эти вопросы…
                                                                  понадобился там сложный datepicker с диапазоном — какую библиотеку выбрать, использовать библиотечный вызов с длиннющим конфигом или в обертку вынести, сложный валидатор отдельным классом сделать или заинлайнить

                                                                  ..., если вы это делаете не в первый раз в жизни? Вы сделаете это точно так же, как делали в предыдущем проекте.
                                                                  Ну и как вы формально проверите, что в этом месте обосновано имя переменной n, а в другом нет?

                                                                  А, да без проблем:
                                                                  bool CheckIsNameValid(string Name) {return true;}
                                                                  Причём я не шучу. Если программист следует общему гайдлайну, там нечего проверять. Любое выбранное им имя окажется уместно, а нюансы рефакторинга «вынести это в метод», как правило, несущественны.
                                                                  • +1
                                                                    Если программист следует общему гайдлайну

                                                                    А как вы это проверите? Речь ведь о возможности формальной оценки качества работы, с результатом "Вася пишет код лучше, Петя хуже, Васе платим больше, Пете меньше".


                                                                    а нюансы рефакторинга «вынести это в метод», как правило, несущественны.

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


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

                                                                    • 0
                                                                      А как вы это проверите?

                                                                      Для этого у него есть начальник/тимлид, у которого есть и необходимая квалификация, и необходимая ответственность, собеседовать людей перед наймом в команду, чтобы убедиться, что они подходят. И проводить review проекта в процессе разработки.
                                                                      Ага, то есть копи-паста теперь вас устраивает? А как же профессиональная подлость и все такое?

                                                                      Не передёргивайте. Я пишу про доверие «по умолчанию» качеству кода квалифицированного программиста, а не про то, что писать говнокод — это нормально. Если вы взяли к себе в команду программиста, которому вы не доверяете, ну кто же вам виноват? Тогда придумывайте, как его контролировать :)
                                                                      Но мне сложно представить вакансию с такими требованиями, обычно наоборот, и швец и жнец.

                                                                      Ну и зря. В разработке бизнес-приложений все тотально занимаются тем, что клепают формы, репорты, бизнес-процессы и синхронизацию/интеграцию. А это едва ли не 90% рынка ПО.
                                                                      • 0
                                                                        > Для этого у него есть начальник/тимлид

                                                                        Ну то есть человек. Я о том и говорил.

                                                                        > клепают формы, репорты, бизнес-процессы

                                                                        Ну так в этом и сложность. Нет заранее готовых бизнес-процессов, которые можно купить и подключить, как батарею.
                                                                        • 0
                                                                          Нет заранее готовых бизнес-процессов, которые можно купить и подключить, как батарею

                                                                          А, понял, почему вы не понимаете :) У вас просто неправильная аналогия. Вы сравниваете бизнес-процесс с уже готовым изделием, которое можно купить и юзать. А бизнес-процесс — это не готовое изделие, это… труба. Труба для данных. Сантехник вам тоже нигде не сможет купить готовую трубу. У него есть несколько сотен разных фитингов, переходников, уголков, разветвителей, и заготовок для труб (разных производителей, разных диаметров, с разными характеристиками, армированием и т.д.) которыми он может свой flow направить туда, куда заказал пользователь. Вот это всё он компилирует в готовый продукт.
                                • 0
                                  Идите работать, нечего тут дискутировать! У нас есть специалист по мотивации, он разберется с вашими задачами. У вас есть профильное образование по психологии? Что? Есть? Не слышу? Ах нет? Ну так идите отсюда и не лезьте со своими идеями.

                                  Тоже мне, умники нашлись!

                                  У меня специалист по персоналу есть, пусть он и занимается этим делом.
                              • +7
                                А надо было сразу увольнять тех программистов
                                И писать код самому
                                • 0
                                  Просто пример упрощённый. Я бы код генерировал. В любых количествах. А ни у кого, в том числе у диреткора, нет способа оценить полезность кода.
                                  • +1
                                    Раз в полгода заказывается аудит у соответствующей конторы. Достаточно недорого выходит, если компания крупная.
                                    • +5
                                      И что делать дальше с грудой лапши, которая копилась пол года, кроме самого осознания факта, что что-то пошло не так?
                                      • 0
                                        То есть мерять надо объём полезного кода? Я вас уверяю, сгенерировать код так, чтобы он вписывался в существующий не очень сложно. Но на худой конец можно начать себе в проект и правда код библиотек копировать, тоже не большое дело.
                                    • +3
                                      Чуть ли не в первой главе учебника по менеджменту Мескона описана разница между мотивацией и стимулированием. И что любая система стимулирования (KPI) будет проэксплуатирована во вред: находчивые сотрудники найдут способ повысить именно показатели. Причем, это отнюдь не только про программистов. А вот мотивация — это гораздо сложнее. Замотивированный сотрудник, прямо как написано в комментарии ниже, работает «за результат и корпоративные ценности». И гордится своей работой. И возможно это, разумеется, только если денег ему хватает.
                                      • 0

                                        И в серьёзных обучающих программах ещё рассказывают про то что замотивировать разными плюшками по сути невозможно, можно создать условия в зависимости от возможностей компании и наблюдая попытаться заинтересовать людей в работе немного меняя их роли и давая обратную связь (а также возможно убирать тех кто совсем не вписывается) :)

                                      • 0
                                        А откуда программистам знать, как будет лучше для компании? Директор сказал «буду платить за строчки кода» — значит, ему нужно много-много строчек кода.
                                        • 0
                                          Ну даже и не знаю, что вас ответить. Мне казалось, программисту очевидно, что компании нужен софт, решающий какие-то там задачи, писать и поддерживать который его, собственно, и наняли. И если ему говорят, дескать, мы тут придумали, как измерить твой объем работы, давай мерить его строчками, у него в голове включается логика (которой он в силу профессии должен быть оснащён по дефолту), что что-то тут не так.
                                          • 0
                                            Очевидно, определение целей компании далеко выходит за рамки компетентности программиста. Если начальство говорит, что нужны строки кода, вероятно, стоит переспросить и уточить, мало ли, где-то было взаимонепонимание. Но если об этом было сказано четко и ясно — ну что ж, значит, компании так будет лучше. Например, она может дальше этот код продавать, и договориться с покупателем об оплате по строчкам кода.
                                            • 0
                                              Очевидно, определение целей компании далеко выходит за рамки компетентности программиста.

                                              Ну так же не бывает в реальной жизни. Вы пишете продукт, вы знаете, что это за продукт, кто его использует, для чего использует. Вы всегда знаете, чем занимается ваша компания, что она продает, производит, какие услуги оказывает. И вдруг вам говорят: «Теперь меряем вашу работу по строчкам кода». Вам для однозначного понимания того, что вам спустили неверную систему мотивации, не нужно быть в курсе каких-то хитрых стратегических планов правления компании. Достаточно лишь той информации, которая вам доступна как обычному разработчику.
                                              • +1
                                                Разумеется, этот момент нужно обсудить с руководством. Но если руководство отвечает «нет, будем оценивать по строчкам кода», значит, либо я, либо начальство неверно понимаем цели и планы компании. И начальству здесь виднее — больше опыта, больше информации, да и вообще должность предполагает ответственность за подобного рода решения. Мне скорее кажется неправильной ситуация, когда каждый дворник вместо того, чтобы делать то, что его просят делать, изобретет какое-то свое «как лучше надо» и будет делать его.
                                                • 0
                                                  Естественно, такой крайний случай тоже можно допустить. Но ведь и диалог в реальной жизни обычно закончится не «делайте, как сказали», а как раз пояснением, почему так. При этом программист в любом случае обязан уточнить, нужно ли ему генерировать бестолковый и некачественный код, или следует писать как обычно, но более «многословно». Потому что вот это как раз его непосредственная ответственность, и он должен понимать, что от него ждут.
                                                  • 0
                                                    Отвечу так. Диалог возможен в том случае, когда директор приходит и говорит — мужики, хочу больше кода/задач/свершений/бабок. Мужики отвечают — директор, базара нет, вот и тебе встречная задача — хотим больше бабок за свою работу.
                                                    Почему когда директор просит с программистов свое — это нормально, и саботаж этого признается чуть ли не преступлением, мол как они могут вертеть на фигу такую хорошую систему? А когда программисты просят свое — это прям ах и ох, как вы можете, и верчение директором их просьб считается нормальным? Хотя ему как директору проще повысить программисту зарплату в Х раз, чем программисту выполнить работы в Х раз больше.
                                                    И пока директора будут саботировать просьбы персонала — персонал считает своим правом саботировать просьбы директора. «Они делают вид что платят, мы делаем вид что работаем» (с)
                                                    • +1
                                                      И пока директора будут саботировать просьбы персонала — персонал считает своим правом саботировать просьбы директора.

                                                      Можно и так, кто же спорит. Но речь шла не про саботаж просьб директора, а про саботаж своей работы, сознательную порчу продукта, который они выпускают. И в этом случае, повторюсь, самым правильным и умным решением проблемы будет увольнение таких сотрудников, и найм новых, как только этот факт всплывёт на поверхность. Не нужны они такие в профессии.
                                                      • +1
                                                        Директор захотел вместо результата получить красивые цифры. Что он от сотрудников хотел — то они ему и предоставили.
                                                        • 0
                                                          Любой директор обычно хочет получить как раз результат (кроме тех случаев, когда ему надо перед акционерами отчитаться :-). А цифры ему нужны лишь как оценка результата. Здесь проблема не в том, что директор захотел показатели, а в том, что ему предложили неудачную систему оценки.
                                                        • 0
                                                          саботаж своей работы, сознательную порчу продукта
                                                          А саботаж ли это?
                                                          Директор ясно дал понять, что продукт будет тем лучше, чем больше в нем строчек кода (иначе почему бы он стал именно за них платить?) А директору уж явно виднее, что лучше для продукта, чем рядовому программисту.
                                                          • 0
                                                            Ну на самом деле, тем способом, что они выбрали, они саботировали не продукт, а систему учета ) Продукт по сути остался таким же. Ну может немного сами себе проблем создали, но не конечным пользователям.
                                                        • 0
                                                          Возможно, я недостаточно это подчеркнул выше, но я абсолютно согласен с тем, что этот вопрос нужно было обсудить с руководством. И в реальности, вполне возможно, удалось бы руководство отговорить.
                                                      • +2
                                                        Насчет реальной жизни. Любой высокий начальник отрывает свою управленческую функцию от производственных процессов, путем внедрения прослоек — топ-менеджеров, HR-ров, экономистов. И те, все облеченные властью как мечом и броней, начинают преследовать свои интересы, захватывая власть и внедряя всякие «нужные и обязательные методики», мотивацию вместо стимуляции, корпоративные ценности вместо премий и разные методики оценки работы вместо адекватной сдельщины. Они в первую очередь преследуют СВОИ интересы, и они умеют это делать. Отличный продажник в первую очередь вор, стригующий процент со сделок, прекрасный экономист в первую очередь режет по живому производство, чтобы показать экономию, HR в первую очередь властитель душ, который ставит свои власть над персоналом превыше прибыли компании.
                                                        И Вы хотите чтобы даже самый развитый программист, доросший до средних должностей начальника отдела, вышел на борьбу с ними аки рыцарь в белых доспехах, прыгнул через их головы и доказал директору, что их работа не помогает, а вредит производству и прибыли?
                                                        Прыгали. На моих глазах прыгали. И расшибались напрочь, ибо они пытаются противостоять людям, облеченным властью, и в конфликте двух человек, один из которых поет дифирамбы и облечен за это властью, а другой приходит и каркает, что все плохо — выигрывает первый.
                                                        • 0
                                                          Жуть-то какая :)
                                                          • 0
                                                            Против HR идти — это рисковать получит увольнение с «волчьим билетом» :(
                                                            • 0
                                                              Идти против них можно. Но это значит что играть ты будешь на их поле, и любой HR в первую очередь поет в уши руководству, что мол все проблемы с персоналом я беру на себя. Человек, пришедший к директору с «жалобой», в первую очередь проблема — пришел и жалуется на какие то дурацкие системы управления. Рефлексы директора не особо то и лучше рефлексов собаки Павлова — письма секретарю, деньги финансисту, человека (персонал) — HR-у. И получается как у Высоцкого: «Кто мне писал на службу жалобы? Не ты?! Да я же их читал!»
                                                      • 0

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

                                                    • +2
                                                      – Понятно. Короче, теперь у нас грейды.
                                                      – Грейдер?
                                                      – Блин, колхоз восьмое марта. Грейды, от английского “grade”, видимо.
                                                      Можно подумать, «грейдер» от какого-то другого слова:
                                                      Гре́йдер (англ. grader, от англ. grade — нивелировать, выравнивать) — прицепная или самоходная машина для планировки и профилирования
                                                      — как раз для разработки планов и профилей для программистов.
                                                      • +1

                                                        По моему единственный способ заинтересовать не только разработчиков а вообще весь персонал — дать опцион, хотя-бы самым ключевым сотрудникам.


                                                        Если пропорционально росту компании будет увеличиваться и прибыль сотрудников — все будут действительно работать на результат, метрики конечно тоже нужно собирать для понимания того что твориться в компании.


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


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

                                                        • +1
                                                          Если пропорционально росту компании будет увеличиваться и прибыль сотрудников — все будут действительно работать на результат...

                                                          А если дела компании пойдут не очень хорошо, такая положительная обратная связь не выйдет ли боком?
                                                          • 0
                                                            Нет, это же опцион. В минус он не работает.
                                                            • 0
                                                              В такой ситуации он только лучше будет действовать. Если у компании начнутся проблемы и перебои с выплатой зарплаты то обычные сотрудники начнут быстро валить (так как ту же зарплату они без проблем получат в другой конторе и без задержек). А вот сотрудники с опционами будут сидеть до последнего, в надежде что все-таки плохие времена пройдут и их опцион таки принесет им много-много денег. А в другой конторе не факт что опцион дадут.
                                                            • 0
                                                              Мотивация без денег — полнейшая чушь. Основная причина, по которой подавляющее большинство людей работает — это деньги. Соответственно логично будет искать те условия, в которых лучше выполняется основная цель всего процесса, т.е. места где больше платят. И от сюда вытекает, что основа мотивации — это деньги.
                                                              Кроме того, всё остальное можно купить за эти деньги.
                                                              • 0
                                                                Мотивация без денег — это волонтёрство.
                                                                • 0
                                                                  А если за работу ещё и платишь?
                                                              • +2
                                                                Но и мотивация ТОЛЬКО деньгами тоже чушь.
                                                                Сужу по себе — ушел с унылой, хоть и высокооплачиваемой работы на более интересную но менее прибыльную, и не жалею. На старом месте почти каждое утро просыпался с ненавистью к окружающему миру. Хорошие деньги эту ненависть могли чуть приглушить только 1-2 дня после зарплаты. Оно того не стоило.
                                                            • +1
                                                              Директору надо было просто дать программистам самим делить между собой бонусы и премии. И если посмотреть на эту «команду», то там быстро бы нашёлся один самый умный(я бы сказал что это был бы «Колян»), который бы и взял бы на себя всю работу HR-щика. А потом надо было просто с ним обсуждать бюджет премий в зависимости от того как выглядят дела у компании…
                                                              • +1
                                                                Вот мне интересно, посему работу руковолителя отдела хотят повесить на HR, они же в специфике или вообще не понимают?
                                                              • +3
                                                                Можно подумать, что для всех остальных сотрудников фирмы (HR, фин. служба, СБ) — удалось найти объективную систему оплаты, только с программистами не получается. А на мой взгляд, с программистами даже проще, поскольку они «продукт» выпускают, а вот как работу службы безопасности «осметить»?
                                                                • +1
                                                                  Да никак, всегда платят оклад, а если ввслужится то можно и премию дать
                                                                • 0
                                                                  Сказка про глупого директора и хитрых программистов?
                                                                  Знаете, я вот программист, уже лет 15 программист. И я считаю что задачи и проблемы надо решать эффективно. Эффективность может измеряться по разным параметрам в зависимости от ситуации и целей.
                                                                  И вот в связи с этим у меня вопрос: Вот у хитрых программистов проблема, в очередной раз навязали метрику. Они понимают что причина проблемы вероятнее всего в недостаточном понимании директором процесса разработки да и вообще слабого понимания зачем им нужен IT отдел ну и желания как то формализировать финансы по нему, то ли мотивировать то ли сэкономить. Вроде первичное и самое эффективное решение очевидно, нужно Коляну или другому самому «хитрому» вытянуть директора и очередного hr-a/консультанта в переговорку и все обсудить. Выяснить и подтвердить корни проблем в взаимодействии и решить как их пофиксить и как проверять. Ну как баг зафиксить или задачу сделать. Даже если не получиться — риск минимален а займет пару часов от силы. Вместо этого мудрим с привлечением пользователей, сами себе ухудшаем код, гамбиты с менеджерами проектов и прочие «хитрости». И страдаем пока директор сам не догадается что стоит пообщаться с программистами напрямую. Мы же гордые, чего это мы должны на всякую директорскую глупость идти и общаться, пусть сам увидит как это плохо работает, а мы поможем.

                                                                  Этим Колянов с Серегами точно результат нужен был, хоть то в удобной им системе мотивации, хоть в «не трогайте нас, платите сколько договорились и дайте делать работу»? Почему-то у меня ощущение что им нужно было что-бы никто не лез в дела IT отдела от слова вообще (мы пишем хороший код, правда непонятно зачем и для чего), и особенно им нужно было доказать что они самые хитрые и смогут саботировать любую систему мотивации.

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

                                                                  P.S. В формализируемые системы финансовой мотивации каждого разработчика не верю, всегда будут недовольные. Верю в рыночную систему определения ЗП (баланс между желаниями работника и желаниями работодателя).
                                                                  • 0

                                                                    У нас была рабочая система где "всё работало" — не без недостатков, но работало. И в какой-то момент пришли "новые залётные" и начали менять "под себя" — и получилось… не как в статье, но тоже не очень хорошо — многие процессы поломались и теперь идёт затыкание дыр. Потому что цель у "залётных" обычно не результат, а устроить движуху. Это обычная проблема, когда залётные что-то там прочитали/услышали и сразу начинают применять, потому что это "модно и современно" (ну или ничего иного не знают/не читали). "Залётные" не спрашивают у участников процесса "что не так?" — им это неинтересно и они в принципе не задаются этим вопросом. Складывается впечатление, что они "творят" по принципу — "авось проканает".
                                                                    P.S. Рыночная система определения ЗП — не работает. Какие бы ни были у работника навыки выше определённой планки з/п не прыгнет по идиотской логике — "ну как мы тебе будем платить зарплату в 5 тысяч евро, если у нас во всём городе/стране максимальная — 2000?" или ещё "лучше": "во всей стране средняя полторы тысячи — мы тебе и так переплачиваем". Лично столкнулся с подобным идиотизмом. Переезд в другую страну, увы, не вариант.

                                                                    • +1
                                                                      Вы говорите что рыночный принцип не канает и тут же доказываете что только он и работает. Есть рынок, есть спрос, есть предложение. Работник для себя выбирает стоит геморроиться с поиском нового места или нет. Бизнес для себя определяет, что дешевле — потерять одного таланта и набарть двух буратин или подымать зп неопределенной группе лиц. Если ты не можешь продать себя в своем городе за 5000 евро — это рынок, детка. Нет спроса или соотношение цена-качество не устраивает покупателя.
                                                                      • 0

                                                                        Боюсь, что в какой мнибудь Тагиле, пришедшего на соискание работы собеседника, потребовавшего себе з/п в 5000 евро и соцпакет на руки быстро отошьют стандартным — "мы вам перезвоним".

                                                                        • +1
                                                                          Если я на базаре выставлю стакан клубники за 1000 евро, можно ли говорить что это нерыночно, раз у меня ее не покупают?
                                                                          • 0
                                                                            Ага, но это больше потому, что Вы не продавец, а, в данном случае, садовод.
                                                                            Если взять клубнику, разложить по коробам разного цвета и с разной ценой, а сбоку на приступочке — маленькое лукошко с клубникой по 1000, то, если по рынку ходит человек с зарплатой в 10+килоевро, есть ненулевая возможность ему это лукошко продать. Психология потребления штука очень своеобразная. В начале 2000х сигареты «Парламент» подросли в продажах из-за единственного маркетингового решения — поднять цену до премиум-уровня.
                                                                            • 0

                                                                              А если это очень хорошая клубника? Без канцерогенов и ещё фиг знает вредного чего, но с прекрасным вкусом? Таким, что вы никогда не пробовали? Упакованная в золотой пакет с ленточкой и пушистой игрушкой?
                                                                              Попрошу отметить, что работодатель покупает не ягоду на один раз, которую съест и всё, а работника на продолжительный срок. Но при этом продолжает применять понятия, как к единоразовому товару. Мало того — товару, на котором ещё и хочет сэкономить. И регулярно, несмотря на то что с опытом обычно характеристики улучшаются, пытается за счёт работника ПОНИЗИТЬ издержки.
                                                                              В своём посте на тему того, что отношения не совсем рыночные, я как раз и имел в виду то, что работники обычно в ХУДШЕМ состоянии, в процессе поиска работы: у потенциального работодателя есть HR, юристы, менеджеры, чтобы вылизать каждый договор и "отфильтровать неугодных", а у работника — всего лишь навыки и, примерно, 10-30 минут уделённого времени, чтобы доказать, что ты крут, людям, которые — просто некомпетентны в вопросе (если до технического интервью дойдёшь — компетентны, но чтобы до него дойти надо потратить время ;))

                                                                              • 0
                                                                                у работника — всего лишь навыки и, примерно, 10-30 минут уделённого времени, чтобы доказать, что ты крут

                                                                                Как я заметил, те кто приезжает на собеседование на очень дорогой машине, и зарабатывает больше, чем те кто приехал на обычной.
                                                                                • 0
                                                                                  И регулярно, несмотря на то что с опытом обычно характеристики улучшаются, пытается за счёт работника ПОНИЗИТЬ издержки.

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

                                                                                    Не обязательно. Ему может требоваться максимально быстро, а может требоваться максимально качественно, и то и другое не получится совместить с максимально дёшево. И каждый работодатель выбирает, что ему из этих трёх важнее, а чем можно и пожертвовать.
                                                                                    • 0
                                                                                      Это понятно. Я просто привёл к общему знаменателю. Все эти «максимально быстро», «максимально качественно» и т.д. все равно так или иначе сводятся к «заработать больше», «потратить меньше». Это просто локальные тактические приёмы.
                                                                                      • 0
                                                                                        Это не просто «заработать больше» и «потратить меньше», так как изменение одного меняет и другое, а увеличить разницу между тем «что заработали» и тем «что потратили», то есть увеличить прибыль.
                                                                                • +1
                                                                                  " примерно, 10-30 минут уделённого времени, чтобы доказать, что ты крут, людям, которые — просто некомпетентны в вопросе" — знаете, вот за последние годы ни разу не было проблемы дойти до технического интервью. Упаковываешь себя в золотой пакет, ленточка сверху и доказываешь hr-у по телефону или скайпу что ты очень хорошая клубника и ей нужно позарез организовать техническое интервью, мы конечно сначала на интервью пообщаемся минут 10-20 с hr, потому что информация о компании и позиции мне нужна до интервью, а потом сразу с технарями и ЛПР. Я не хвалюсь, просто себя нужно тоже ценить и покорно идти по 2-5 интервью только потому что hr так привыкла — потеря времени.

                                                                                  «что работники — обычно в ХУДШЕМ состоянии» — я и нанимал, и собеседовал и сам искал работу, пока статистика такая — найти человека на проект сложнее чем устроиться на хорошую работу самому. Найти человека в свою компанию на долгосрок — еще сложнее. Учитывая время входа в средний проект и другие факторы, давая свое согласия работодатель, инвестирует в работника где-то 3-6 его ЗП, даже с испытательным и даже если уже в первый месяц понятно что человек его не прошел и пора расставаться. Работник рискует только 2-4 неделями на поиск новой работы, хотя чаще и ими не рискует так как работодатель обязан предупредить заранее. Так что нет, нормальное состояние, даже в чем то выигрышное. И навыки важнее договора, который обычно типовой, да и его прочитать можно вдумчиво и спросить и изменить если что не устраивает, хитрых уловок там обычно нет, смысла просто нет, раб программист обладает эффективностью стремящейся к нулю, ну а если критично то можно и дать на проверку внешнему юристу фрилансеру, не такое уж это и дорогое удовольствие учитывая возможные последствия. И договор вот он на столе, а навыки еще проверить надо, что тоже риск, собеседование далеко не полностью проверяет.

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

                                                                                  «отфильтровать неугодных» — ну все логично, вы же тоже не отправляете резюме в каждое рога и копыта и не отвечаете согласием каждому hr-у? Кстати, обычно работа hr-a в основном заключается в том что-бы найти и заинтересовать, и на это уходит процентов 90 времени, а не отфильтровать тех кто сам обратился. Исключение госы где работники нужны раз в год и для галочки.

                                                                                  «за счёт работника ПОНИЗИТЬ издержки» — ну не за счет, а с учетом. Сэкономить на ЗП работника после найма 5-10% просто глупо, упавшая мотивация сьест гораздо больше эффективности. Ну а так да, если вы придете на собеседование на позицию которая обычно стоит 3К и попросите 5К то скорее всего скажут нет. Особенно если это аутсорс и заказчик платит 4К, да и в продуктах тоже умеют считать деньги. Фишка в том чтобы находить позиции где готовы платить 5К и иметь достаточные скилы для нее. То же и с повышением ЗП, TerraV верно описал принцип.
                                                                          • 0
                                                                            залётные что-то там прочитали/услышали и сразу начинают применять, потому что это «модно и современно» (ну или ничего иного не знают/не читали). «Залётные» не спрашивают у участников процесса «что не так?» — им это неинтересно и они в принципе не задаются этим вопросом. Складывается впечатление, что они «творят» по принципу — «авось проканает».

                                                                            Они делают это, чтобы показать начальству «смотрите какие мы — крутые, и какие лохи — кто тут давно работает».
                                                                            • 0

                                                                              Да. Потому что подспудно они начальствоми и наняты, чтобы "всё поменять и получить конфетку". Проблема в том, что чтобы получить конфетку — надо для начала въехать в текуущий процесс, чтобы не наломать дров, а это время. Плюс — из работников обычно никто не будет откровенничать с "залётными" вот так запросто: они прийдут и уйдут, а работнику тут ещё работать. Если же начальство нанимает "залётных", а время идёт и ничего (движухи и изменений) не происходит — начальство спрашшивает уже "залётных": какого хрена вы делаете, мы для чего вас нанимали? Вообщем, для залётных куда ни кинь — всюду клин. Жадность начальства, неадекватность залётных, интровертность работников — и вот вместо конфетки фигня какая-то получается. Неудобоваримая =)

                                                                            • +2
                                                                              Тут сложно судить, конкретно у вас я не был. Есть в практике как и ситуации когда «старожилы» привыкли и воспринимают проблему как норму, как ноющий зуб который вроде болит но к стоматологу идти не охота. Так и молодые но амбициозные и излишне активные менеджеры, которые не разбираясь в проекте пытаются перекроить его в эталонный скрам.

                                                                              Но если людей наняли значит проблемы были, и «старожилы» их не решили, а то и не воспринимали как проблему и не хотели решать. Или не обладали достаточными возможностями и авторитетом чтобы решить. И это как ни странно тоже их вина. Не было лидера который бы взвалил на себя и тянул решение проблемы или убеждение руководства что это не проблема, нет его и сейчас чтобы обьяснить руководству и «залетным» что они совершают ошибку. Может это и не так, но в основном происходит в таких ситуациях именно так. Можно найти такого лидера, а лучше просто всем пообщаться со всеми сторонами, проявить инициативу, может они и все правильно делают, но вы этого не видите, человек не может быть профессионалом во всем, хороший программист может быть плохим менеждером даже если он проработал 10 лет на этом продукте и наоборот. Ну или уволиться, одному или всем. Тоже вариант, рыночный. Можно еще потерпеть и привыкнуть, перестроение процессов всегда боль, даже если команда всеми руками за, а уж если против то сильная и долгая боль. Тут что комфортнее надо выбирать. Но выбирать нужно. Просто выбрать и признатся в первую очередь самому себе что выбор сделан, и сделан самостоятельно, а не его навязали, сразу проще становиться. Сорри за нравоучения, но как же это жалко и нелепо когда взрослые люди ноют и думают что все решают за них, а они лишь беспомощные винтики в этой бездушной машине. Начальник дурак а от нас ничего не зависит. Сколько раз это видел, и каждый раз не понимал зачем так себя унижать. А начальники в это время жалуются на безинициативных сотрудников, погрязших в рутине, и на необходимость нанимать новых, которые ничерта не разбираются и не скоро разберется но у них хотя бы есть желание исправить проблемы.

                                                                              Да, напрягает это слово, «залетные», в духе «он не из нашего района, что он может вообще знать» своячество этакое, сами создаете границу и формируете конфликт как те программисты в посте. От которого все потом будут героически страдать. Зато гордо и независимо и своей тесной компашкой.

                                                                              Это все конечно же ИМХО из моего общего опыта на десятках проектах на разных позициях и с разных сторон этой «баррикады», делать выводы по одному коменту почти невозможно, все предположения.
                                                                              • 0

                                                                                Для того, чтобы решить проблему — необходимо:


                                                                                1. Понять в чём именно проблема
                                                                                2. Иметь ресурсы и полномочия её решить.
                                                                                  В случае "местной" команды — у них есть первое, но нет второго.
                                                                                  В случае "залётных" (уж извините буду продолжать использовать, для краткости) — у них есть второе, но нету первого и это сильно хуже (ИМХО), чем предоставить ресрсы разрабам.
                                                                                  Статья раскрывает проблему как "слишком дорого платить разрабам", что выглядит не как проблема, а как самодурство, а потом ещё и впривлекают "специалистов", которые в принципе отказываются вникать в проблему, а сразу переходят к решению.
                                                                          • +5
                                                                            Откуда в Тагиле знают про React? И, главное, кто им на нём писать разрешил? На Delphi же ещё лицензия не закончилась.