Как эффективно управлять командой удаленных программистов 1С

27.07.20

Команда

Дистанционная работа становится все популярнее, и многие компании задумываются о том, что, возможно, стоит попробовать работать с разработчиками на удаленке. Но чтобы такое сотрудничество было эффективным, придется не только контролировать код на выходе. Нужно еще научиться взаимодействовать в условиях разных часовых поясов, вести учет отработанного времени, уметь удержать и заинтересовать работника. О том, как эффективно управлять удаленной командой высококвалифицированных программистов 1С, на конференции Infostart Event 2019 Inception рассказал руководитель компании «Крон» Ранис Усманов.

Добрый день. Меня зовут Ранис Усманов, я руководитель компании «Крон». Свою компанию я создал за полтора года, и сейчас в ней трудится 38 высококвалифицированных разработчиков. Плюс я запустил сервис по онлайн-собеседованию программистов 1С.

 

О себе

 

 

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

Я являюсь сертифицируемым преподавателям 1С и автором сертифицированных курсов.

Сегодня я хотел бы поделиться своими навыками и опытом по созданию аутсорсинговой компании удаленных программистов 1С.

 

О чем доклад

 

 

Секцию «Управление персоналом» на конференции я выбрал не просто так. Я считаю, что кадры решают все.

И сегодня мы рассмотрим следующие моменты:

  •  как собрать команду: как привлечь сильных разработчиков к себе;
  •  как организовать эффективную работу разработчиков и настроить их на максимальную клиентоориентированность;
  •  как добиться хорошего учета и контроля времени;
  •  как добиться закрытия часов – не менее 150 в месяц по каждому сотруднику;
  •  как организовать работу сотрудников в разных часовых поясах;
  •  какие бывают системы мотивации, кроме заработной платы;
  •  как эффективно решать проблемы, возникающие при работе;
  •  и рассмотрим некоторые категории сотрудников – такие как «герой», «интроверт» и «пассажир».

 

Как собрать команду

 

 

Первый вопрос – как собрать команду и привлечь сотрудников.

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

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

  •  финансовая стабильность;
  •  возможность заниматься только разработкой;
  •  нормированный график;
  •  профессиональный и карьерный рост;
  •  команда компании.

Эти топ-5 критериев я выбрал не просто так. За последние три года я прособеседовал более 2000 кандидатов – это дало мне возможность собрать информацию, что мотивировало их принять предложение от работодателя, а что демотивировало, какие были причины сменить работу.

  • Почти 100% разработчиков сейчас хотят видеть финансовую стабильность в лице самого работодателя. Они хотят получать всегда вовремя ту зарплату, о которой они договаривались с работодателем при приёме на работу. Зарплата не должна зависеть от оплаты клиентов, от выработки, от простоев и каких-то необоснованных штрафов. Нам придется с этим мириться, потому что сейчас очень много компаний, которые предлагают примерно те же самые оклады, выплачивая их вовремя и стабильно. Поэтому мы обязательно должны предоставить разработчику некую финансовую стабильность.
  • Следующий пункт – заниматься только разработкой. Работа с конечными пользователями – один из наиболее сильных демотиваторов для разработчиков. Речь идет про обучение, консультирование и получение задач от сотрудников компании-клиента – бухгалтеров, экономистов, финансистов и т.д. Этой работой все-таки должны заниматься именно консультанты или аналитики – именно они должны ставить задачу перед разработчиком. Ни в коем случае не подключайте к этому конечных пользователей. Разработчики должны заниматься разработкой и получать задачи только от консультантов и аналитиков. Но, конечно, если вы хотите, чтобы разработчик быстро ушел по собственному желанию, то можно его отправить на обучение пользователей.
  • Нормированный график. Надо понимать, что сильные разработчики – это люди, которые знают цену своему времени и самим себе. Плюс это люди от 25 лет, у которых уже есть семья, некие увлечения и обязательства, на которые тоже надо уделять время. Причем нормированный график – это удобно для разработчика, а также выгодно для работодателя. Потому что при нормированном графике вы можете получить максимальную эффективность от работы сотрудника. Если вы не предоставляете ему нормированный график, то его эффективность будет похожа на американские горки, что очень бьет по прибыли.
  • Если говорить про профессиональный и карьерный рост, то 60-70% разработчиков поставили профессиональный рост выше карьерного роста. Потому что сильные специалисты очень много времени и сил потратили на то, чтобы получить свою квалификацию, и для них, как минимум, очень важно ее поддерживать. А лучше – повышать. У меня есть разработчики, которые ко мне пришли только из-за того, что на предыдущей работе у них не было возможности поддерживать свою квалификацию. И это огромный риск – они боятся, что со временем станут неконкурентоспособными на рынке. Я уже не говорю про то, что им неинтересно делать какие-то мелкие задачи. Так что нам всегда нужно уделять время на то, чтобы предоставлять возможность разработчикам как минимум поддерживать свою квалификацию, а лучше – повышать ее. Мы, к примеру, собираем карту знаний разработчиков, получаем информацию, где у них есть какие-то пробелы, стараемся их  подтягивать. В целом мои разработчики как раз за счет этого и хотят дальше работать в нашей компании.
  • 30-40% рассказали о желании карьерного роста – стать, к примеру, руководителями проектов, архитекторами и т.д. Конечно, не все могут предоставить возможность карьерного роста, но надо попытаться это давать.
  • Последний критерий – команда компании. Здесь подразумевается следующее: половина наших кандидатов хотят работать в сильной команде. Сильная команда – один из хороших источников для повышения квалификации. Это некий подпункт к профессиональному росту.

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

 

Как организовать эффективную работу

 

 

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

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

  •  мы потеряем клиента;
  •  мы понесем убытки;
  •  мы получим негативный отзыв от клиента.

 

 

Лучше эту информацию доносить в ключе выгоды самого сотрудника.

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

Если доносить информацию в таком ключе, то вы получите максимальную эффективность. Разработчик будет сам заинтересован работать максимально эффективно и по правилам компании.

 

Учет и контроль времени

 

 

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

Я пробовал различные методики, читал разные книжки, использовал всевозможные системы. Но все свелось к минимуму:

  • Мне самому, как работодателю, выгодно, чтобы сотрудники заносили часы вовремя, правильно и ежедневно. К примеру, появилась задача, ее заносят в систему, по каждому заданию делаются записи о работе – что сделали и сколько времени на это потратили. Я не прошу своих разработчиков писать «Войну и мир» в трех томах и описывать вплоть до строчки, что они поменяли. Это бессмысленно и невыгодно.
  • Моя логика простая – запись должна сама себя продавать. Клиент должен понимать, за что он платит, и на что у него время уходит. Если разработчик может уложить описание работы в одном предложении из трех слов, клиент доволен и понимает, за что он платит, меня это устраивает.

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

  • Моя помощница в 8 часов утра в общий чат пишет примерно следующее: «Доброе утро, занесите, пожалуйста, часы за вчерашний день. Спасибо!». 80% сотрудников, которые до этого времени не занесли часы, уже это делают.
  • В 10 утра по мск идет электронное оповещение о необходимости занесения часов за вчерашний день. Это предупреждение о том, что после 12 часов редактировать ничего нельзя. На этом этапе все, кто не успел, тоже заносят свои часы, и у нас сейчас проблем нет.
  • Раньше нам приходилось использовать еще третье правило: обращаться к руководителю, когда период редактирования закрыт. Разработчики обращаются ко мне, чтобы внести изменения или занести часы.

Но перед тем как открыть период, я им всегда доносил информацию о том, что им самим выгодно занести информацию вовремя:

  • Опять же приводил в пример лояльного клиента, говорил об их выгоде в ключе лояльного клиента, показывал, где именно мы можем получить лояльность. Ведь когда клиент всегда может оперативно получить информацию о своих затратах – что конкретно было сделано, сколько на это времени было потрачено, мы все получаем некую лояльность – и компания, и сам сотрудник.
  • Отсюда идет еще одна его выгода от лояльного клиента – довольный руководитель. Иными словами, если человек всегда заносит часы вовремя, всегда правильно, клиент доволен, у меня нет проблем по выставлению счетов, мы получаем положительные отзывы, и все это идёт человеку в копилку, и как минимум, это очень хороший повод его премировать, а может, и повысить ему заработную плату.
  • Кроме того, это экономия времени. Дело в том, что когда я доношу всю эту информацию сотруднику, я доношу ее от получаса до нескольких часов. Мы с разработчиком сидим, рассуждаем о выгоде, какие могут возникнуть моменты и так далее. И получается, что если бы он ежедневно правильно и вовремя заносил часы, то он тратил бы максимум 5 минут в день. А в противном случае он будет со мной общаться полчаса-час, бывало, и до 3 часов доходило. Правда, после такого общения человек больше никогда не захочет дойти до 3 пункта, и сейчас у нас все заносят часы корректно и вовремя – до 12 часов по мск.

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

 

О закрытии не менее 150 часов в месяц

 

 

Следующий момент – это закрытие часов не менее 150 часов в месяц.

  • Когда мы запускались, мы использовали такое правило: если разработчик видит, что у него задача заканчивается через полчаса, час, день, то он обязательно должен предупредить об этом клиента и руководителя. Если человек уже по факту скажет, что у него задачи закончились, мы не всегда сможем оперативно дать ему работу. Действительно, у нас есть пул задач, но не всегда можно все бросить и уделить время на пояснения по постановке. Я доношу следующую информацию: я плачу за каждый час вне зависимости от простоев и выработки и хочу, чтобы каждый час было максимально эффективным. Здесь должно быть некое взаимоуважение. Поэтому разработчику необходимо предупреждать клиента и руководителя заранее, чтобы мы подготовили и предоставили ему пул задач. Это помогало, но все равно было около 20-30 часов простоя на сотрудника в месяц.
  • Меня это не очень устроило, и мы сделали следующее. В нашей системе мы создали панельку с мелкими задачами, которые были не срочные, их и через неделю можно было решить. К каждой задаче имеется маленькое описание и предварительная оценка по времени выполнения. И когда разработчик уходил в простой, и мы не могли ему оперативно дать задачу, он благодаря предварительной оценке мог выбрать подходящие по времени выполнения задачи. Это нам помогло сократить количество простоев до 5-6 часов на сотрудника в месяц.
  • На сегодняшний день у нас все разработчики загружены на full-time, работают по 8 часов в день 5 дней в неделю, от месяца и более на клиента. Это нам сократило количество простоев до 0. Здесь я немного согрешил: за последние два месяца – июль и август – мы получили грандиозное количество простоев: 12 часов на 38 разработчиков. Но мы пытаемся добиться, чтобы клиенты хотели работать с нами на full-time благодаря заинтересованности сотрудников, максимальной эффективности и клиентоориентированности. Сейчас у нас проблем с простоями нет.

 

Организация работы сотрудников в разных часовых поясах

 

 

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

  • Первый. Клиент находится в том же часовом поясе, что и разработчик. Сейчас в России очень много ведется внедрения и сопровождения 1С, и по всем областям идет дикая нехватка сильных разработчиков. И вы можете найти и клиента, и сотрудника, которые находятся в одном часовом поясе. И тогда всем будет хорошо.
  • Если у вас нет такой возможности, например, у меня разработчики находятся от Барнаула до Калининграда, то есть второй способ – сделать сдвиг рабочего времени +/- 4 часа. У меня есть клиент, который работает в Москве с 9 до 18, а мои разработчики, к примеру, начинают работать в 4 или 5 утра. Здесь самое главное, чтобы разработчик вовремя получал пул задач с неким описанием и пояснениями по ним. Мне кто-то говорил, что такой вариант работы подходит для малого и среднего бизнеса, а крупные компании и госкомпании никогда ни в коем случае не согласятся так работать – они диктуют свои правила. Но на самом деле это не так. У нас сейчас большой пул крупных клиентов – крупные российские компании, крупные международные компании, и мы с ними работаем в режиме +/- 4 часа сдвиг. Все довольны, и никаких проблем нет.

 

Система мотивации, кроме заработной платы

 

 

Какие есть способы мотивации:

  • Самое простое – это найти повод, чтобы поблагодарить сотрудника. Например, если вы получили положительный отзыв, или сотрудник повысил квалификацию, обязательно поблагодарите его. Поблагодарите перед всеми. Вы же понимаете, что сильные разработчики – это творческие люди, а любая творческая душа требует признания. Достаточно просто поблагодарить перед всеми, сказать, что благодаря работе Васи Пупкина нам прислали положительный отзыв, спасибо ему. Это дает некий стимул разработчику и дальше быть максимально эффективным и клиенториентированным.
  • Работа в команде – еще один способ мотивации. Она очень хорошо помогает повышению квалификации. Раньше мы каждому разработчику индивидуально закупали какие-то курсы, или я сам их проводил. Но особого эффекта не было – курсы откладывались в долгий ящик. Потом получилось так, что один из наших разработчиков создал чат под названием «Философский чат по программированию», и все втянулись в это дело. Там частенько обсуждают разные моменты по оптимизации, по производительности, по новым механизмам, методикам и стандартам 1С. Обсуждают, как лучше сделать, как будет более оптимально и правильно. Я к этому время как раз прекратил закупать всякие курсы, прекратил что-то преподавать и решил посмотреть, насколько такое общение будет эффективно. Через 3 месяца, когда мы проверили знания, я увидел, что у разработчиков в среднем на 5-10% повысилась квалификация. У некоторых сотрудников были проблемы с обменами, с оптимизацией, и они подтянулись в этих темах благодаря работе этого чата. Причем, они никак не включались, другие ребята сами обсуждали, как будет оптимально и правильно.

 

 

  • Следующий момент: обязательно информируйте сотрудников, какие цели мы ставим перед собой, куда мы движемся, чего мы хотим достигнуть, как мы планируем этого достигнуть, и что нам для этого нужно сделать. Для каждого человека всегда нужны какие-то новые цели. Поэтому информируем людей о планах и целях компании. В дальнейшем, когда мы достигаем этих целей, обязательно необходимо сообщать сотрудникам, что мы достигли цели, объяснять, благодаря чему мы их достигли, что мы от этого получили, и в чем выгода для самих сотрудников. Если сотрудники видят ваши достижения, видят цели компании, они верят в вашу компанию и с энтузиазмом работают. Если вы не будете выдавать информацию, чего вы достигли, какие у вас показатели и так далее, то обычно сотрудники начинают теряться, они начинают считать, что компания никуда не движется, у них начинают возникать какие-то негативные эмоции.
  • Поэтому всегда необходимо информировать людей о достижениях и планах компании. И мы обязательно доносим информацию, как мы это сделаем, что мы получим, и в чем выгода именно сотрудников. Никогда нельзя забывать рассказать, в чем будет выгода самого сотрудника.

 

Эффективное решение проблем, возникающих при работе

 

 

Здесь всего два пункта:

  •  оперативность;
  •  руководить всегда открыт и готов помочь.

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

  • К примеру, проблема с технической частью. Человек 10-15 минут не может решить какую-то задачу, бывает такое. Лучше сообщить об этом в чат, коллеги обязательно помогут. Даже можно обратиться к руководителю, и если будет возможность, я обязательно подключусь и помогу. Тут опять доносится информация, что если он пытается сам решить эту задачу, то может потратить на это день-два. Из-за этого мы получаем некий негатив от клиента, теряем его лояльность, а разработчик теряет некую свою выгоду. Поэтому лучше решать эти проблемы оперативно.
  • Если, к примеру, возникает какой-то негатив в коммуникации с клиентом или какое-то недопонимание, тоже обращайся, пожалуйста, к руководителю. Мы подскажем, как себя вести по своему опыту, сам руководитель может подключиться, чтобы проблему решить. Если это затягивать, то, скорее всего, будет опять какой-то негатив со стороны клиента, причем обоснованный, и самому разработчику будет тяжело работать.

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

 

Категории сотрудников: герой, интроверт и пассажир

 

 

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

Герой 

Это моя самая любимая категория сотрудников. У героя есть множество положительных сторон, но есть и свои минусы. Положительная сторона: за счет своего героизма человек в принципе может вытянуть весь ваш проект. Если горят сроки, проект тонет, то именно эти сотрудники благодаря своим ресурсам вытянут проект. Они могут перерабатывать по 14-16 часов, работать 7 дней в неделю несколько месяцев подряд. Это не очень хорошо, но за счет этого героизма они частенько вытягивают проекты. Клиенты остаются довольными, мы получаем положительные отзывы.

Но есть и минусы, и на них надо акцентировать свое внимание. Первый минус в том, что если вы подключаете такого героя к клиенту, клиент, ясное дело, доволен, какой разработчик молодец, вытянул проект. Но когда вы подключаете второго сотрудника, не героя, который тоже сильный разработчик, но работает стандартно, не геройствует (не работает по 10-12 часов), то клиенту будет казаться, что второй разработчик более слабый по сравнению с первым. Тут приходится доказывать и объяснять клиенту, что проблема не во втором, а по большей части в первом. Потому что герои – это исключение, и таких ребят маловато.

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

Героев очень тяжело контролировать, чтобы они не перерабатывали. Частенько вы даже не будете знать, что человек перерабатывает. Он просто будет работать ради компании, ради проекта, ради клиента. Не будет это афишировать.

 

 

Интроверт 

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

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

Пассажир 

Самая не любимая моя категория, но, тем не менее, с ними работать можно. Просто надо понимать следующее: если вы наняли сотрудника-пассажира с определенной квалификацией, с этой квалификацией он и будет работать. Их никак нельзя мотивировать на клиентоориентированность, на максимальную эффективность, на повышение квалификации и т.д. Они уже достигли своей цели, когда к вам пришли на работу, они получили ту зарплату, которую они хотели. Больше их ничего не интересует. Исключением по повышению квалификации может быть только то, что они получили некое задание, где есть механизм, который они до этого не изучали. В этом случае человек изучит механизм, но изучит ровно настолько, чтобы выполнить поставленную задачу.

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

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

Если хотите двигаться вверх и вперед, лучше все-таки использовать героев и интровертов.

На этом у меня все. Если появятся какие-то вопросы, я могу рассказать более детально.

Большое спасибо!

 

 

Вопросы

 

  • Как вы контролируете удаленных сотрудников? Не секрет, что у каждого опытного 1С-ника, как минимум, 1-2 своих клиентов, с которыми они приоритетно работают. Поэтому возникает много вопросов, когда надо выбрать между вами, удаленной работой, и своим клиентом, который требует выполнения.
  • Когда мы принимаем на работу, я сразу доношу информацию, что мы работаем по 8 часов в день, мы всегда должны быть в онлайн, не должно быть такого, что 10-15 минут клиент не может достучаться до разработчика. Плюс наши клиенты сами могут оценить задачу. К примеру, если человек отработал 2 часа, а записал 8 часов, это могут оценить наши клиенты, можем оценить мы. И в этом случае мы просто сразу прощаемся.
  • Но как именно вы их контролируете?
  • Лично я каждое утро здороваюсь. Когда люди уходят на обед, они тоже отчитываются. И мне, и клиенту. Я объяснил уже, зачем нам это надо. Но в целом получается, что мы всех своих разработчиков подключаем напрямую к клиенту, и им задачи поступают в течение 8 часов все время. Куда-то отлучиться, переключиться на другую задачу нет возможности. Если человек переключится, то быстро возникнет вопрос, где разработчик, и даже если он окажется на связи, его всегда спросят, чем ты занимался.
  • А как вы контролируете переход ваших сотрудников к клиенту непосредственно? Ведь, если клиент контролирует его, если он им доволен, то есть вариант предложить работать сразу на него.
  • Насчет переманивания. Нашим разработчикам более комфортно и удобно работать лично со мной, в нашей компании. Потому что мы финансово стабильны, у нас хорошая зарплата, мы даем возможность заниматься только разработкой и работать в сильной команде. Если они переходят к другому клиенту, то я помешать этому никак не могу.
  • Получается, что вы их уговариваете?
  • Я их не уговариваю. Я просто предоставил им возможность заниматься своим любимым делом и получать хорошую заработную плату вовремя и стабильно. Плюс у нас всегда различные проекты. Если он уйдет к конечному клиенту, то, скорее всего, он не будет заниматься только разработкой. Его еще загрузят консультированием, обучением и так далее. И это будет один проект на долгие годы.
  • Штрафы с клиентом вы проговариваете?
  • Нет. Понимаете, если какие-то штрафы выставлять, это можно расценивать как нарушение прав самого сотрудника. Я не имею права препятствовать ему менять работу.
  • Насколько я знаю, таким образом поступают аутсорсинговые компании, поэтому я и хотел уточнить.
  • Я понимаю. Но у меня такого примера ни разу не было. Хотя были моменты, когда моим сотрудникам предлагали перейти, но сотрудники сразу мне сообщали, что их пытаются переманить.
  • Скажите, у вас разработчики работают напрямую с конечным пользователем, консультантом от заказчика или у вас есть свои аналитики, консультанты?
  • У меня свои консультанты-аналитики есть, но они тоже работают full-time. Разработчикам ставит задачи консультант или аналитик со стороны клиента. И я их не подключаю к конечным пользователям. У меня есть один клиент, где можно работать с конечными пользователями, но он только один. Дай бог таких клиентов всем и побольше.
  • Какую схему мотивации вы используете: окладную, сдельную или окладно-премиальную?
  • Оклад. Я им гарантировано всегда выплачиваю оклад, независимо от простоев. Простои и выработка – это все зависит от меня. Оплатил клиент или не оплатил – это опять же моя проблема, потому что я клиента привел.
  • Никаких KPI, ничего такого нет?
  • Нет. Но задача какая? Мы работаем максимально эффективно, клиентоориентированно, а если человек так не работает, то мы с ним просто прощаемся. У меня человек либо работает, либо не работает.
  • Вы продаете клиентам конечные часы или готовый продукт?
  • Часы.
  • Правильно ли я понимаю, что если у вас не готов еще целиком какой-то механизм, который запросил клиент, счет ему будет выставлен все равно – на эти часы?
  • Тут есть разные варианты. Если по оценке работать, тогда уже конечный результат идет. А если на full-time, как сейчас у нас, то оплачивается каждый час. Но если смотреть по оценке и по full-time, то лучше второй вариант – от разработчика эффективность выше. Потому что на него не давит эта оценка, сроки и так далее. Он в более расслабленном состоянии, он быстрее выполняет задачи.
  • Как клиенты относятся к тому, что они оплачивают часы, а не готовые продукты? При этом у программиста, как я понимаю, нет особой мотивации быстрее завершать работу. Или это вообще не проблема?
  • Это опять сводится к тому, что если человек не будет эффективно работать, то мы с ним просто не будем работать – он потеряет работу, финансовую стабильность и возможность заниматься любимым делом.
  • А как оценивается эффективность? Вы знаете норму часов на каждую задачу или как?
  • Скажем так: я сам в предыдущей кампании считался одним из самых сильных разработчиков и могу оценить работу и количество потраченных часов.
  • Т.е. у вас 30 программистов, и вы за каждым следите? Или у вас есть какая-то система контроля эффективности? Я просто не понимаю. Если у них оклады, то за 30 работниками или больше следить как-то нереально.
  • Наши клиенты – это фирмы франчайзи или  крупные конечные клиенты, у которых есть свои отделы сопровождения и свои программисты, которые сами могут оценить эффективность. Если человек работает неэффективно, они мне об этом сообщат. Плюс каждый месяц я стараюсь брать у того или иного клиента отзыв по сотруднику, некий фидбэк. Иногда мы с разработчиком просто созваниваемся, обсуждаем, какая задача сейчас решается, сколько времени на это тратится. Иногда я могу попросить показать программный код, чтобы посмотреть, насколько грамотно человек пишет.
  • Вы сказали, что у сотрудников только оклад, зачем тогда отмечать часы?
  • Эти часы мы потом выставляем клиентам.
  • В какой системе вы ведете учет задач?
  • В 1С. Я наклепал по-быстрому.
  • Когда разработчику поступает конкретная задача и ему необходимо уточнить постановку, как это происходит?
  • Подключаем к клиенту. Постановкой задачи занимаются консультанты-аналитики. В основном нам все задачи ставят в устной форме, у нас нет опыта с ТЗ. Если разработчик видит какие-то неточности или ему что-то нужно прояснить, он обязательно сообщает об этом и уточняет задачу. Если он видит более оптимальные варианты, как сделать интереснее, он обязательно тоже их предлагает клиенту.
  • Как вы планируете загрузку внешних разработчиков?
  • У меня сейчас только одна проблема: где бы найти еще 10-15 разработчиков…
  • А среди тех, что есть, как вы распределяете нагрузку, чтобы не было провалов по срокам?
  • Они у меня находятся на full time, а проекты идут от нескольких месяцев до полугода. Есть клиенты, которые мне просто сказали: забудь про своих разработчиков, они с нами надолго.
  • Я правильно понимаю, что вы работаете только с франчайзи, а с конечным пользователем фактически вы не работаете, он к вам не обращается?
  • С конечными клиентами мы работаем, но работаем не для внедрения, а как сопровождение. Например, есть какая-то компания со своим штатом разработчиков. Допустим, один человек уволился, и им нужно закрыть эту дырку в кадрах. Они к нам обращаются. И также фирмы франчайзи, когда у них не хватает собственных ресурсов для проектов, а проектов сейчас много.
  • А как вы в этом случае боретесь с «паранойей»? Потому что большинство компаний, особенно крупных, не готовы давать доступ к своим данным.
  • Такая проблема бывает иногда. Были клиенты, которые предлагали такой заход в их сервер, что приходится работать на коленках. Разработчикам неудобно, и мы просто стараемся не работать с такими клиентами. Для меня разработчики очень важны, и мне важно, чтобы им работа нравилась. Но у большинства наших клиентов проблем с этим нет, они спокойно предоставляют доступ к серверам или к какому-то рабочему месту, где наши разработчики уже работают.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

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

Коммуникации Бесплатно (free)

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

27.02.2024    863    0    user1561517    3    

8

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

Мотивация Бесплатно (free)

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

13.02.2024    765    0    izybaevda    5    

15

Радио "Аналитик", 12 выпуск 2 сезона. Про архитектуру, архитекторов и аналитиков в сфере IT c Александром Кварцхава. Часть 2/2

Проектирование Проектирование бизнес-процессов Управление конфликтами Кейсы продуктов Бесплатно (free)

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

05.02.2024    436    0    Radio_Analyst    0    

1

Диагностика команды в преддверии больших изменений

Фасилитация Бесплатно (free)

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

25.01.2024    381    0    suhovnina    0    

1

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

Сейчас на рынке много объемных проектов, и специалисты часто сталкиваются c перегрузками. Чтобы сохранить ресурсное состояние и не допустить выгорания, нужна личная работа человека и грамотный подход руководителей. В статье рассказываю, как мы помогаем сотрудникам справиться со стрессом.

15.01.2024    1699    0    KChebykina    0    

31

DevRel: почему им стоит заняться уже сегодня

Коммуникации Обучение и наставничество Бесплатно (free)

DevRel (developer relations или просто технический пиар) – направление развития и поддержки IT-бренда компании: почти как PR (Public Relations), только в центре внимания находятся технические процессы и технологии, а не маркетинг. О том, зачем DevRel нужен компаниям, какие есть форматы, кто уже запустил DevRel, что из этого получилось, и почему это становится трендом, пойдет речь в статье.

09.01.2024    1606    0    a_plastinin    2    

16

Завал в IT-компании и как с ним бороться

Коммуникации Россия Бесплатно (free)

Работа в режиме завала и в режиме нарастающего завала. Для простоты изложения возьмем конвейерное производство. Конвейер традиционно делится на участки (на множество участков). На каждом участке конвейера есть сотрудник, который выполняет определенный процесс или занимает позицию «наблюдателя» - стандартный руководитель. Представим картину: на таком производстве в середине смены, кто-то упустил определенный момент и все, что находится на конвейере падает на пол. Вот тут и начинается: "Все бегают, суетятся и проклинают виновника и в экстренном порядке пытаются придумать «что-то»".

25.12.2023    696    0    simon_sidoruk    1    

5

Синергия аналитика и разработчика

Коммуникации Бесплатно (free)

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

19.12.2023    820    0    Fecolka    1    

8
Отзывы
2. Богатырев Артур 125 27.07.20 12:38 Сейчас в теме
Интересная статья, без шуток. Немало здравых и хороших моментов и методов, особенно в части отметок отработанного времени.

Несколько наблюдений и вопросов:
1. Оценка и эффективность программиста оцениваются по личным наблюдениям руководителя и отзывам клиентов. Тут есть возможный небольшой недостаток на будущее - с ростом количества разработчиков это все более и более трудно делать лично. Ясно, что контролировать 10 человек легче чем 100.

2. Позиционировать программистов только как программистов тоже не всегда получится - человек может легко захотеть уйти из кодеров в аналитики, например. Более того, есть много задач, когда программист должен проявлять навыки аналитика. Конечно, в теории он может получать только готовые уже задания от аналитика, как это описывает автор статьи. Но тут же небольшое противоречие, как пишет автор - они не работают с ТЗ, только прямое устное общение.

3. "Разработчикам ставит задачи консультант или аналитик со стороны клиента. И я их не подключаю к конечным пользователям."
Если честно, то тут как то странно - получается что программист таки напрямую взаимодействует с неким человеком от клиента, а конечный это пользователь или нет - какая разница? Разработчику то все равно - это конечный бухгалтер или спец из местного айти-отдела, лишь бы отвечал на вопросы, ставил задачу, принимал ее.
Вообще тут очень тонкий и непонятный момент - кто несет ответственность за поставленную задачу (что она была сформулирована именно так)? Если программист ее не ставит, то он вроде не несет. Но правда жизни такова, что клиент в случае чего - свалит все на программиста. В отсутствие ТЗ все скатится на уровень "сам дурак".
Вообще, автору бы добавить пункт - как он обычно разруливает конфликты с клиентами.

4. Работаем за еду... в смысле за оклад.
Чистая окладная система имеет всем известный недостаток низкой мотивации - система "оклад (ну например 80-90% дохода) + бонусы" эффективнее. Например за переработки, за быстро и круто сделанный проект. Автор здраво замечал о возможных похвалах работнику и т.п., но денежные бонусы тоже вещь приятная.


5. Насколько я понимаю, работники не приняты в штат, а работают по договору ГПХ.
MaZZZ; Kolobash95; +2 Ответить
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. DBTransformer 27.07.20 12:19 Сейчас в теме
Спасибо, ценный материал
2. Богатырев Артур 125 27.07.20 12:38 Сейчас в теме
Интересная статья, без шуток. Немало здравых и хороших моментов и методов, особенно в части отметок отработанного времени.

Несколько наблюдений и вопросов:
1. Оценка и эффективность программиста оцениваются по личным наблюдениям руководителя и отзывам клиентов. Тут есть возможный небольшой недостаток на будущее - с ростом количества разработчиков это все более и более трудно делать лично. Ясно, что контролировать 10 человек легче чем 100.

2. Позиционировать программистов только как программистов тоже не всегда получится - человек может легко захотеть уйти из кодеров в аналитики, например. Более того, есть много задач, когда программист должен проявлять навыки аналитика. Конечно, в теории он может получать только готовые уже задания от аналитика, как это описывает автор статьи. Но тут же небольшое противоречие, как пишет автор - они не работают с ТЗ, только прямое устное общение.

3. "Разработчикам ставит задачи консультант или аналитик со стороны клиента. И я их не подключаю к конечным пользователям."
Если честно, то тут как то странно - получается что программист таки напрямую взаимодействует с неким человеком от клиента, а конечный это пользователь или нет - какая разница? Разработчику то все равно - это конечный бухгалтер или спец из местного айти-отдела, лишь бы отвечал на вопросы, ставил задачу, принимал ее.
Вообще тут очень тонкий и непонятный момент - кто несет ответственность за поставленную задачу (что она была сформулирована именно так)? Если программист ее не ставит, то он вроде не несет. Но правда жизни такова, что клиент в случае чего - свалит все на программиста. В отсутствие ТЗ все скатится на уровень "сам дурак".
Вообще, автору бы добавить пункт - как он обычно разруливает конфликты с клиентами.

4. Работаем за еду... в смысле за оклад.
Чистая окладная система имеет всем известный недостаток низкой мотивации - система "оклад (ну например 80-90% дохода) + бонусы" эффективнее. Например за переработки, за быстро и круто сделанный проект. Автор здраво замечал о возможных похвалах работнику и т.п., но денежные бонусы тоже вещь приятная.


5. Насколько я понимаю, работники не приняты в штат, а работают по договору ГПХ.
MaZZZ; Kolobash95; +2 Ответить
3. Ranis1286 182 27.07.20 14:54 Сейчас в теме
(2)
Добрый день.
1) Благодаря моему сервису я спокойно могу проверить знания своих программистов, а также нахожу время для тех, кому еще надо было подтянуть знания, чтобы понимать подтянул он их или нет. Также обязательно ставим его на проект по тем темам, где ему надо было подтянуть знания. Т.е. он сначала обучается по курсам, делает несколько практических задачи по нашим внутренним проектам, а далее подключаем к клиенту.
2) Согласен, именно поэтому сейчас некоторые наши программисты становятся архитекторами, тимлидерами, РП. Один стал моим заместителем.
3) Аналитик, консультант, РП это все таки не конечные пользователи, как бухгалтер, менеджер по продажам и т.п. В любом случае, если возникают вопросы, то программист не остается один на один с постановщиком задачи, а я или мой зам подключаемся, чтобы понять, что было не так. Так как я и мой зам. подкованы очень сильно в разработке, то можем оценить адекватно был ли пролет по часам или нет. Также наши разработчики при получении задачи задают вопросы, чтобы клиент получил именно тот продукт, который ему нужен и чтобы не было проблем потом типа того, что друг друга не поняли.
4) Переработки это зло, так как теряется эффективность программиста. Наша задача максимально эффективно работать по 8 часов в день. Те у кого проблемы с самомотивацией, т.е. нужен человек, который будет ему напоминать, что он получает одну из самых высоких заработных плат в удаленке, мы с такими просто не работаем. В целом у наших программистов с мотивацией и ответственностью все хорошо. Были пару программистов, которые начинали просиживать 8 часов, но, как я и сказал: "либо работает, либо нет". В итоге да хотели вернуться обратно, якобы все поняли, но с подобными личностями я не работаю.
5) Работники все приняты в штат, иначе не мог бф платить отпускные, больничные и т.п.
Alenaru; Богатырев Артур; +2 Ответить
7. Богатырев Артур 125 27.07.20 15:40 Сейчас в теме
Спасибо, все прояснили.

(3)
Благодаря моему сервису я спокойно могу проверить знания своих программистов, а также нахожу время для тех

Ага, значит на самом деле есть некий сервис (способ, метод) оценки.

(3)
Переработки это з

Я не о переработках писал, а о мотивации. Не напоминания, а бонусы.
Кстати выше вы сами писали о типе разработчика "герой" (у вас вообще хорошая классификация) - он то вообще обожает перерабатывать... :)
Впрочем я нашел место, где вы пишите сами что на самом деле мотивация у вас далека от уравниловки "просто оклад": " за положительный отзыв дать сотруднику премию одноразово или вообще повысить ему заработную плату". Мой вопрос сам снялся.
Но тогда у вас не окладная, а все таки окладно-премиальная система. :)

(3)
Работники все приняты в штат, иначе не мог б

А вот это действительно круто по нынешним временам.
Ranis1286; +1 Ответить
44. Cyberhawk 135 09.08.20 10:22 Сейчас в теме
(3)
нужен человек, который будет ему напоминать, что он получает одну из самых высоких заработных плат в удаленке
А сколько нынче вилка на руки?
45. Ranis1286 182 10.08.20 14:18 Сейчас в теме
(44) скоро на митапе расскажу) Пока не могу выдавать инфу, которая в основе выступления
49. 1cccc 13.10.21 21:36 Сейчас в теме
(2) Я заметил, что есть такие управленцы, которые даже из окладной системы выжимают максимуму за счет навыка микроменеджмента т.е. просто давят по-максимуму или ищут трудоголиков-фанатов, которым в удовольствие работать много даже за фикс. оплату.

Не думаю, что это сильно интересно, когда 10-20% дохода капает бонусами. Слишком это мало и проще эти 10% каким-то леваком поднять за 2-3 вечера, чем вот так вот.
4. kotov2000 5 27.07.20 15:16 Сейчас в теме
Раскройте, пожалуйста, тему, как Вы так быстро прощаетесь со своими кодерами не нарушая ТК.
Учитывая, что у них оклад прописан в трудовом договоре.
6. Ranis1286 182 27.07.20 15:28 Сейчас в теме
(4) Т.е. Вы хотите сказать, что без нарушений попрощаться с сотрудником никак?) Лично у меня пока получается не нарушая ТК, и не собираюсь нарушать.
p.s. честно очень надоели вопросы, которые можно интрепретировать, как обвинение в нарушении ТК, оплате З/П черными и т.п. Вся З/П белая, нарушений в ТК нет.
Богатырев Артур; +1 Ответить
8. Богатырев Артур 125 27.07.20 15:45 Сейчас в теме
(6) я думаю, вопрос все таки не суть обвинение, это реально интересно.
9. Ranis1286 182 27.07.20 17:36 Сейчас в теме
(8) Всегда расставались по обоютному согласию с выплатами отпускных и прочее)
Богатырев Артур; +1 Ответить
12. Богатырев Артур 125 27.07.20 20:19 Сейчас в теме
(9) я вас понял, спасибо
Ranis1286; +1 Ответить
5. niko11s 988 27.07.20 15:17 Сейчас в теме
Герой

Это моя самая любимая категория сотрудников.


Героизм одних - это преступление и разгильдяйство других.
ubnkfl; Rollam; starik-2005; user733468; morin; +5 Ответить
10. user1145418 27.07.20 19:03 Сейчас в теме
Ранис, если вы работаете без ТЗ: как оценивается время? Взять отчёт: нужна картинка, правила заполнения полей и т. п. для того чтобы оценить время на реализацию; причём даже при наличии такой картинки есть вещи которые для консультанта само собой разумеющиеся (отчёт должен быть на скд с возможностью настроек в пользовательском режиме) а у разработчика своя картина мира (нарисовал жесткий макет ровно как на картинке)
Второй вопрос - контроль качества: какие этапы проверки/тестирования выполняет разработчик перед тем как передать доработку клиенту?
13. Ranis1286 182 27.07.20 22:23 Сейчас в теме
(10)Ни один программист не будет рисовать макет без острой необходимости, так как это муторно) В любом случае обсуждается с заказчиком. Если программист видит, что без макета ни как, то 100% предупредит. Если заказчику надо, то можем дать интервал времени за сколько будет сделано. Чтобы дать точную оценку, да и в целом, чтобы клиент получил, то что он хочет задаем вопросы)
В целом разработчики ответственные, профессиональные и адекватные, что уже гарантирует честную работу без завышения часов работы. Также большинство клиентов могут сами оценить + я сам сильный разработчик и если возникнут спорные моменты. то я сам могу оценить всю проделанную работу.
Разработчики проверяют свою доработку(открытие формы, правила расчета, заполнения и т.п.). Но сейчас активно начинаем использовать сонар куб и еще несколько обработок для теста. Также вводим edt с git, чтобы любая доработка, отчет, обработка имела свой номер релиза + автотесты и т.п.
В общем в этом году проделываем большую работу по стандартам разработки, работы с клиентами, использование edt, git, sonarqube, чтобы в следующем году выйти ещё более качественной и профессиональной командой.
11. lmnlmn 69 27.07.20 19:17 Сейчас в теме
Прям описание рая программиста!
14. Ranis1286 182 27.07.20 22:24 Сейчас в теме
(11) Ну до него еще далеко) Но я знаю программистов и что для них хорошо, а что нет, так как сам являюсь программистом
15. a_a_burlakov 285 28.07.20 04:39 Сейчас в теме
Спасибо за доклад, интересно. Есть вещи, которые смутили, но наверняка многим руководителям будет что подчерпнуть.

Вопрос: не расскажете поподробнее, как организовано (если организовано) обучение сотрудников? В докладе есть фраза: "где у них есть какие-то пробелы, стараемся их подтягивать". Это "подтягивание" в чём выражается?
16. itmind 308 28.07.20 05:37 Сейчас в теме
Несколько вопросов:

1. Оценка необходимого времени на решение задачи субъективна. Вы как сильный разработчик оцениваете так, как если делали ли бы вы. Но все люди разные: кто то медленнее печатает, кто то педантичнее, кто то перфекционист и вылизывает код до идеала. Т.е. у каждого программиста на выполнение задачи уйдет разное время и это время не зависит от его квалификации. Так же нужно учитывать, что не все программисты в команде "сильные" и если вам требуется 1 час на решение, то средне статистическому разработчику потребуется 3 часа. Так же бывают случаи, когда разработчик спотыкается на какой то проблеме, которую было не видно до начала разработки и это существенно увеличивает время.
Как вы решаете эти проблемы с оценкой в часах? просто прибавляете несколько часов к вашей оценке?

2. Проблема прокрастинации. Человек не может продуктивно работать много часов или дней подряд. (Вы об этом написали в описании Героя)
Часть рабочего времени забирает коммуникация внутри отдела, поиск оптимального решения, эксперименты в коде, чтение профильных статей, заполнение задачника, различные отчеты о проделанной работа, митинги, совещания и т.п., да даже обсуждение каких то событий происходящих в жизни (особенно если несколько человек сидят в одном кабинете). Получается в задачу нельзя это время включать, т.к. скажут "долго выполнял" и попрощаются. Не включать это время в отчеты - в месяц будет не доработка по часам (а вы в часах мерите эффективность разработчика).
Что вы делаете с этим выпадающим рабочим временем?

3. Вы упомянули про "одну из самых высоких зарплат на удаленке". А разве есть сейчас разработчики которые ездят к заказчику и сидят где то там за предоставленным закачиком ПК (например в углу склада)? Все работают удаленно: подключаются на сервера, ПК. Даже сидя в офисе у нас сотрудники все работают на серверах и благодаря этому любой сотрудник может работать например с дома в случае необходимости (даже тех поддержка, офисные телефоны переадресуются на мобильные).
Почему вы делите уровень зп "удаленщика" и "офисного работника" если все работают удаленно?
Так же на вашем сайте указана цена 1100-1400 руб на фултайм для заказчика. Получается, что фирма либо зарабатывает всего 300 р. с часа, либо разработчику платится меньше чем 1000 р./час, а это ниже ставки хорошего специалиста.
Ronin; morin; +2 Ответить
17. morin 57 28.07.20 10:34 Сейчас в теме
(16) Вопросы по делу. Как-то уж очень бегло в докладе упомянуты проблемные и спорные места.
40. Ranis1286 182 04.08.20 14:47 Сейчас в теме
(16) Добрый день. Прошу прощения, что сразу не ответил. Завал задач и т.п.
1) Наши клиенты сами могут оценить задачу, так как это фирмы франчайзи или крупные компании со своим штатом. Набираем только сильных специалистов и благодаря их навыку и знаниям разработка идет быстро. Также я сам сильный разработчик и могу оценить сколько времени на это пнядобится( в спорных моментах могу до деталей разобрать все).
2) Не может работать без потери эффективности, если работать более 8 часов без перерыва и более 5 дней в неделю. Именно поэтому мы против переработок. Сам работал по 8 часов в день 5 дней в неделю и знаю, что возможно и эффективность не страдает. А вот если брать, к примеру по 12-16 часов в день без выходных, то ДА, надолго не хватит и будешь в один момент работу 2 часовую решать неделю. По экспериментам и т.п. снова спасает опыт, также ясное дело, что время на тест, отладку время занимает, но ведь без этого ни как. Одно дело количество времени теста, отладки после работы middle, а другое после senior. У senior так называемый "Технический долг" существенно ниже. Да, мы эти часы выставляем, а кто не выставляет?) В оценку туже все закладывают риски, отладку и т.п. Просто у нас благодаря низкому "техническому долгу" и профессиональному подходу в получении задачи, изучении задачи и т.п. риски уменьшаются, время на отладку и т.п. тоже.
3) "Удаленка" имеется виду работа удаленная для сотрудников из регионов. Я не говорю про программистов из Мск, которые работают удаленно. Наценка наша действительно маленькая, но за счет сильных специалистов получается получить эффективность с каждого часа рабочего в месяце.
41. Богатырев Артур 125 04.08.20 16:54 Сейчас в теме
(40)
аши клиенты сами могут оценить задачу, так как это фирмы франчайзи или крупные компании со своим штатом.

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

(40)
В оценку туже все закладывают риски, отладку и т.п

Так заказчик может иметь свою оценку.
42. Ranis1286 182 05.08.20 18:03 Сейчас в теме
(41)
м франчайзи помощь других франчайз? Есть тут только один вариант - аутстаффинг.
И потом - оценка заказчика и вас может различаться существенно. Что дел

"аутстаффинг" - не аутстаффинг)
Если не сойдемся с оценкой, то не делаем. В целом у нас всегда обоснованная оценка и проговариваем все детально
43. Богатырев Артур 125 06.08.20 10:29 Сейчас в теме
(42) т.е. налицо обычные переговоры с оценкой.
Ranis1286; +1 Ответить
18. Dach 372 28.07.20 11:01 Сейчас в теме
(0) Ваш сайт https://cron-plus.ru не особо UX, честно говоря

Зарегал учетку, как проходить тесты - непонятно. Туториалов нет. Написал в тех. поддержку - чата нет, мое сообщение исчезло. Вы его еще тут и рекламируете? Рили?
19. Dach 372 28.07.20 11:11 Сейчас в теме
(18) при добавлении резюме требует кучу перс данных заполнить. Вы их безопасно храните, надеюсь?
38. Ranis1286 182 04.08.20 14:32 Сейчас в теме
(19)Само собой разумеется
37. Ranis1286 182 04.08.20 14:32 Сейчас в теме
(18) Добрый день. Кажется Мы ответили Вам. Тесты если хотите пройти, то покупайте.
20. Dach 372 28.07.20 13:02 Сейчас в теме
(0) ради интереса попробовал пройти собеседование

- вопросов 60, я честно и развернуто успел ответить на 38 и потратил на это 1 час времени. После 38 вопроса остальные просто уже пропустил, тратить больше 1 часа на техническое интервью - моветон

- на нескольких вопросах видел такое поведение пишешь-пишешь ответ, еще есть время для отправки ответа - нажимаешь, вист, вист, висит и.... следующий вопрос!
39. Ranis1286 182 04.08.20 14:33 Сейчас в теме
(20) Ну сильные спецы в течении 40 минут в среднем отвечают, middle примерно 1-1.5 часа. За то получаете полную выкладку знаний и что нужно подтянуть.
P.S. многие проходят и не видят в этом проблемы))
21. Поручик 4670 28.07.20 15:36 Сейчас в теме
22. morin 57 28.07.20 21:49 Сейчас в теме
(21) Что ж в ней хорошего? По-моему, описана чисто тепличная работа тепличных программистов в тепличных условиях:
- за кадром оказалась работа консультантов, аналитиков, методологов, т.е. есть разработчики, они занимаются только разработкой и всё типо прекрасно. Кто и как ставит задачи не понятно. Как организовано общение с представителями со стороны заказчика, уточнение требований, внесение изменений в задание? Всё получается сразу и с первого раза? Заказчик тоже тепличный? Как решаются споры, конфликты? Заказчик сразу подписывается за все часы молча?
- как организована работа команды разработчиков с большими и долговременными проектами? Как решается проблема legacy-кода? Вообще, проекты документируются? Как организовано устранение ошибок предыдущих разработчиков? Куда выставляются часы за эту работу? Есть ли система учета ошибок? Как новый специалист входит в сложный, кастомный проект, получает задачу и долбится с отладчиком до посинения?
Ronin; a_a_burlakov; +2 Ответить
25. Поручик 4670 29.07.20 09:25 Сейчас в теме
(22) Разработчики и должны работать в тепличных условиях. Иначе разработчику быстро осторчертеет такой вот бля%ский цирк, он найдёт и свалит на место покозырней.
Разработчик должен заниматься разработкой, а не решать проблемы за тупых юзеров.
23. TempAvtoteh 29.07.20 08:18 Сейчас в теме
Хм... Почитал тут коменты и хочется ответить как клиенту Крона.
1) Все тут рассматривают со стороны Исполнителя. Встаньте на место Заказчика.
2) На рынке реально проблема найти хорошего спеца. У нас контракты практически со всеми федеральными франчайзи и могу сказать, что меня из подход к работе крайне не устраивает. Свою базу работников они раздули, а реальных сильных спецов не так много и их бросают либо дыры закрывать, либо на крупных клиентов, где разговор о десятках миллионов. А с тобой работает в лучшем случае программер, хорошо сдавший на "Специалист", но мало имевший реального опыта и на тебе, за твой же счет он этот опыт приобретает. И чёрт бы с этим, да вот только это дорого по времени и качеству кода (не говорю про деньги).
3) Этот святой грааль ТЗ. Шаг влево, шаг в право - расстрел. С одной стороны да, Вы всё описываете в ТЗ, согласовываете и спокойно всё по нему делаете. Вы прикрыты. Вот только маразмы бывают не только со стороны Заказчика, но и со стороны Исполнителя. Наш реальный пример. Мы заплатили Исполнителю (крупнейший франчайзи) за составление ТЗ, он его составил, согласовал с нами, взялся за работу и через полгода сменил всю команду и запросил в 2 раза больше денег. обговоренных в контракте, т.к. "всё оказалось сложнее". Т.е. полгода по ТЗ шпарили, а потом оказалось, что ТЗ не совсем такое. И на Заказчика не сопрешь, т.к. сами и составляли. Господа, хватит за ТЗ прятаться. Если заказчик выкатывает не подробнейшее ТЗ, где чуть ли не весь код, а вам только ручками его перебить, то будьте добры все же подстроиться под клиента, а не наоборот. Я не спорю, что Заказчик должен это оплатить, но при этом Заказчик должен получить требуемое, а не кучу бумаг с непонятной ему писаниной, на которую потом будут кивать Исполнители, мол Вы сами подписались. Вот только подписываемся мы под тем что нам понятно, а не под технической реализацией, которую мы Вам и заказываем. Ладно бы 1 раз, но так с разными крупными франчайзи происходило неоднократно. При этом мы не меняли требования или что-то еще. Мы вполне адекватный заказчик.

Крон нам порекомендовали. Имея негативный опыт, мы с сомнением отнеслись к ним, тем более особо про них не слышали. Договор с полгода только заключали. И то решающий фактор стала цена по акции. И, внезапно, мы получили что давно искали: понимание. Мы говорим что хотим, как можем, а получаем то, что нам надо. Без тягомотины согласования, утверждения и т.п. Проговорили, ответили на уточняющие вопросы и смотрим на результат. На тесте снова уточнили, если что-то надо, то довели / поменяли и в работу. Баги отловили и пошли дальше. В принципе, этобы и решил свой такой спец в штате, но Вы попробуйте его найти. Рынок пылесосят и хэдхантят так, что тут бы своих не потерять, не то, что нового нанять. Короче, Крон нам нужного специалиста предоставил по очень хорошей цене. С федеральными франчайзи мы так и не смогли придти к единому согласию.
Это не пост рекламы )) Просто реальный отзыв от реального клиента. Нашу проблему компания решила полностью.
gmw; Ranis1286; o.nikolaev; user1239818; Богатырев Артур; +5 Ответить
24. Богатырев Артур 125 29.07.20 08:53 Сейчас в теме
(23) Хочется немного защитить, так сказать, свою отрасль. :) Кстати спасибо вам за очень жизненный отзыв
а рынке реально проблема найти хорошего спеца. з

Вы не представляете, как трудно это сделать и Исполнителю.

(23)
Свою базу работников они раздули, а реальных сильных спецов не так много и их бросают либо дыры закрывать, либо на крупных клиентов, где разговор о десятках миллионов. А с тобой работает в лучшем случае программер, хорошо сдавший на "Специалист"

1. Мы молчим про раздутые штаты Айти-отделов на предприятиях.
2. Сильных специалистов в любом деле мало. Часть их них в штатных айти-отделах.
3. Как ни покажется странным, привет всем из капитализма, но сильные специалисты всегда направляются только на выгодные проекты. У нас не СССР.
4. Дипломы сданные в 1С часто вообще ничего не значат, как ни покажется это кощунственным. Реально имеет значение количество и уровень проектов, с которыми работал человек.

(23)
ыта и на тебе, за твой же счет он этот опыт приобретает.

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

(23)
его составил, согласовал с нами, взялся за работу и через полгода сменил всю команду и запросил в 2 раза больше денег. обговоренных в контракте, т.к. "всё оказалось сложнее". Т.е. полгода по ТЗ шпарили, а потом оказалось, что ТЗ не совсем такое. И на Заказчика не сопрешь, т.к. сами и составляли.

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

(23)
Господа, хватит за ТЗ прятаться. Если заказчик выкатывает не подробнейшее ТЗ, где чуть ли не весь код, а вам только ручками его перебить, то будьте добры все же подстроиться под клиента, а не наоборот. Я не спорю, что Заказчик должен это оплатить, но при этом Заказчик должен получить требуемое, а не кучу бумаг с непонятной ему писаниной, на которую потом будут кивать Исполнители, мол Вы сами подписались

Тут неизбывный конфликт. Увы, но ТЗ необходимо как в любом инженерном процессе. Странно требовать от строителя, чтобы он вам выстроил новый цех или смонтировал линию без ТЗ?
И да, обе стороны любят прикрываться ТЗ. Одна - чтобы не сделать больше чем в ТЗ, другая - чтобы получить больше. Заказчик часто вообще гораздо хуже понимает объем работ (тут вы верно заметили с "непонятной писаниной").
И часто заказчик по этой причине плохо представляет, почему он не может заплатить условно 100 тысяч и получить коммунизм.

(23)
Ладно бы 1 раз, но так с разными крупными франчайзи происходило неоднократн

Выскажу свое исключительно личное пристрастное и неадекватное мнение - но у меня ощущение, что уровень франчайзи (федеральщики или регионалы) - далеко не всегда напрямую связан с качеством организации и исполнения проекта. Также не секрет, что крупные франчайзи (генпордрядчик) в Москве для крупных же проектов, особенно федерального уровня - привлекают на субподряд "мелкачей", удаленщиков, или просто крупные региональные франчи - просто потому что их ценник ниже московского в 1.5-2 раза. Лично был привлекаем на такие проекты - и в первые разы прифигевал от уровня организации - ну все таки федеральный уровень, а там как ребята из студобщаги собрались.

За качественную работу Крона - желаю искренне им удачи и больших денег (без шуток). :)
Ranis1286; Поручик; user1239818; +3 Ответить
27. TempAvtoteh 29.07.20 09:45 Сейчас в теме
(24) Как бы я не то, чтобы нападаю на отрасль, скорее ною о сложившемся положении дел )))
Я как бы согласен, что не коммунизм, я о деньгах вообще не упоминал, за всё надо платить и никто не спорит. Но вот платить то надо адекватно. По Вашей же аналогии никто не заплатит вчерашнему студенту медику ЗП уже матерого стоматолога. Если я приду в клинику и мне этот медик начнёт что-то не так делать, то я начну разбираться, жаловаться и скандалить. И тех денег не заплачу, что запросят за супер-пупер спеца. Здесь же хотят как за мегаспеца, а дают окончившего курсы вчерашнего студента. Да ради бога, только давайте тогда обговорим его ценник.
Далее ТЗ. Мне, как Заказчику вот глубоко на него. Это Исполнитель им прикрывается. А мне важен результат. И всё равно с ТЗ или нет. С клиентом надо работать, а не формализовать отношения посредством ТЗ. Ситуации разные бывают, конечно. Но для этого и кормится у фирм разного рода менеджеры по работе с клиентами и т.п. И их задача, по моему мнению, не развести клиента на проект, а выяснить его потребности и, главное, как с ним работать. С кем то надо жестко по ТЗ, а с кем то по выяснению потребности и т.п.
Франчайзи сейчас - это "зерг-раш". Налетим, заключим а там как пойдет. Главное массовостью брать, а не качеством. На место 1 недовольного клиента приведут 2. Вот только такая тактика "выжженной земли" хороша на средний срок. О неэффективности работы с франчайзи говорят многие. Зато это кормит такие организации как Крон. В принципе я за подобного рода профессиональные артели. Потому что мне нужен качественный результат, а не "и так сойдет, работает же". Может быть и настанет время, когда количество перейдет в качество,но пока есть, что есть. Ну и плюс это все же монополия. А монополия никогда не была выгодной для клиента.
30. Богатырев Артур 125 29.07.20 10:34 Сейчас в теме
(27)
Если я приду в клинику и мне этот медик начнёт что-то не так делать, то я начну разбираться, жаловаться и скандалить. И тех денег не заплачу, что запросят за супер-пупер спеца

Для этого и существует договор на работы - в котором среди прочего предусмотрены разные санкции нерадивым подрядчикам. Ну например, оплата пост-факта работ (хотя все подрядчики просят предоплату) или еще что-то. Бюрократия в России священна.

(27)
Да ради бога, только давайте тогда обговорим его ценник.

Это хорошая идея, так и нужно ее предлагать подрядчику. В конце концов это ж не СССР, когда вам за ваши деньги одолжение делают - это подрядчик заинтересован в ваших деньгах.

(27)
Мне, как Заказчику вот глубоко на него. Это Исполнитель им прикрывается

Глубоко зря так думаете. ТЗ в том числе сделано, чтобы вы могли достать кнут и пороть подрядчика, если он вам что то не сделал. В ТЗ написано - реализовать блок складского учета, чтобы там под управлением 1С квадрокоптеры летали? Написано. А подрядчик не сделал. Значит никаких денег за этот блок. Вернувшись на пример стройки - если у вас нет ТЗ, то вам прораб построит вместо трехэтажного цеха с зоной погрузки и воротами - подземный бункер. И не придерешься, он "так понял".
При этом ТЗ конечно на мелких работах реально не нужно, или нужно в примерном виде.
В конце-концов вы можете попасть на тривиальное непонимание - вы хотите квадрат, а подрядчик искренне решил что нужен треугольник.

(27)
С клиентом надо работать, а не формализовать отношения посредством ТЗ.

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

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

Да, согласен. Тут правда работа менеджера (что примерно ему нужно и как с ним работать), а потом аналитика (что именно нужно клиенту в рамках 1С).

(27)
Франчайзи сейчас - это "зерг-раш". Налетим, заключим а там как пойдет

Это далеко не про всех. Я не рекламирую, но например, компания в которой я работаю, так не делает. Хотя горькая правда есть в ваших словах про многие компании.

(27)
Вот только такая тактика "выжженной земли" хороша на средний срок. О неэффективности работы с франчайзи говорят многие. Зато это кормит такие организации как Крон. В принципе я за подобного рода профессиональные артели

Я целиком тут с вами согласен. Бракоделам бой. Они позорят всех, кто занимается 1С
33. TempAvtoteh 29.07.20 11:00 Сейчас в теме
(30) Ну нам вернуть деньги за неисполненное ТЗ помогло не его наличие, а не подписанные Акты. Я не говорю, что ТЗ не нужно, я говорю, что всё должно быть адекватно и согласно потребности клиента. Клиенты тоже разные бывают и вполне неадекватные тоже, прикрыться ТЗ неплохо, но сходу записывать всех в неадекваты, наворачивать многостраничное ТЗ, где хорошо, если сами Исполнители разбираются и за каждое отступление от него в плане нам надо было, чтобы мы получили результат, а в результате мы это не получили, хотя по ТЗ вроде всё ровно (из того, что мы поняли) еще сверху лупить ценник - это как то перебор. Я вот чувствую себя обманутым.
Далее, как предложить подрядчику снизить цену, если она в договоре установлена и он утверждает, что вот на нас самый лучший спец. работает. Вот и корочки. Не нравиться - ну давайте мы договор ИТС заключим, на 100-200р. вам ценник уроним и все счастливы должны быть. Это русский наебизнес - клиентам ИТСки подписываем, 1C кучу программеров с сертом "Специалист" показываем, а как на самом деле проекты идут - да всё равно, лучше рекламный бюджет увеличим, да продажников посноровистее наймём. В итоге клиенты - быдло, прогеры - рабы, галера плывёт. Профит!
34. Богатырев Артур 125 30.07.20 09:29 Сейчас в теме
(33)
а не подписанные Акты.

Хороший вариант, кстати.

(33)
что всё должно быть адекватно и согласно потребности клиента. Клиенты тоже разные бывают и вполне неадекватные тоже, прикрыться ТЗ неплохо, но сходу записывать всех в неадекваты, наворачивать многостраничное ТЗ

Подписываюсь. :)

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

Не все подрядчики плохие
36. TempAvtoteh 30.07.20 09:56 Сейчас в теме
(34) Пока, в неплохие подрядчики, могу только Крон записать (из тех, что сейчас имеем). Уверен, что есть еще варианты, но как-то устал проверять и разочаровываться. Вообще всё зависит от специалиста. И у федералов могут хорошие попасться, но мне пока не везло.
26. Поручик 4670 29.07.20 09:30 Сейчас в теме
(23) Если встать на место Заказчика, то у него два выбора - искать до бесконечности спеца, который устроит всех, или жрать, что есть в этой стране. Других-то нет.
Со времён эпохи Петра Первого мало что поменялось.
28. TempAvtoteh 29.07.20 09:50 Сейчас в теме
(26) Согласен. Но тут кивают на рыночные условия. Правда забывают, что эти условия не работают в условиях монополии.
31. Богатырев Артур 125 29.07.20 10:35 Сейчас в теме
(28) монополии нет. Франчайзи множество, они все конкуренты друг друга.
Нельзя же назвать "монополией" наличие легковых автомобилей? Автосервисов то множество.
32. TempAvtoteh 29.07.20 10:47 Сейчас в теме
(31) Монополия есть. Я, как клиент, ощущаю это на себе. С другой стороны это ощущается менее, но всё же. Стоны программеров 1С, в том числе в закрытых чатах телеги - тому подтверждение. Если бы у 1С был реальный конкурент, то разговоры бы клиентов, в первую очередь, были другие.
35. Богатырев Артур 125 30.07.20 09:29 Сейчас в теме
(31) монополии нет. Франчайзи 1с множество, они все конкуренты друг друга.
Нельзя же назвать "монополией" наличие легковых автомобилей? Автосервисов то множество.
46. ip0593 20 25.01.21 16:46 Сейчас в теме
(23)а что, судиться с исполнителем - крупным франчайзиром совсем не вариант?
47. Богатырев Артур 125 25.01.21 17:02 Сейчас в теме
(46) так это время и деньги. Но судится можно.
29. o.nikolaev 211 29.07.20 10:20 Сейчас в теме
48. ITSun 18.08.21 18:12 Сейчас в теме
Материал интересный, но автор себя пиарит на непонятных аргументах.

"Я 4 года считался одним из сильнейших разработчиков в аутсорсинговой компании".
Простите, в КАКОЙ, сколько там было специалистов, какова специализация компании?

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

Теперь автор открыл ООО и пишет слоган на Инфостарт "Если Вы пришли к нам, то Вам есть чем гордиться. Вы один из лучших в России".
А на чём это утверждение основано?

Уважаемый, автор, вы не хотите подкрепить свои слова ссылками на проекты, отзывы и прочее?

Без обид, но складывается впечатление, что вы работали где-то как-то, далее вам надоело (не получалось заработать), вы погуглили чужой "успешный" опыт и стали ещё продавать курсы. Далее подкопили средств (скинулись с друзьями на стартовый капитал), составили бизнес-модель с сервисом по аутстаффу (галера?) и далее пиаритесь и привлекаете клиентов.
Такое впечатление складывается, но я и раньше ошибался.
50. Ranis1286 182 26.11.21 15:44 Сейчас в теме
(48)
далее вам надоело (не получалось заработать), вы погуглили чужой "успешный" опыт и стали ещё продавать курсы. Далее п

Добрый день. Спасибо) Много нового о себе узнал)) Я то все думал, как я бизнес открыл, а вот оно что оказывается: подкопил)))
Оставьте свое сообщение