Распределенно ДА или распределенно НЕТ? Интервью для тех, кто по полгода не может найти себе разработчика

    В предверии тимлид-завтрака «Удаленная команда. Начало» мы поговорили с техническим директором компании wemake.services – Никитой Соболевым (sobolevn). Несмотря на то, что поиск разработчика, тем более опытного — страшный сон тимлида или менеджера проекта, немногие пока решаются перейти на работу с удаленщиками. Никита же несколько лет назад решил эту задачу кардинальным образом. Как? Давайте разбираться!



    Дальше в интервью будут фигурировать двое: интервьюер (И.) и Никита Соболев (Н.)

    О способах работы вообще и количестве точек контроля


    И.: Практически все тимлиды и менеджеры разработки жалуются, что они никак не могут найти себе разработчика в офис. Особенно в регионы. Возьмем для примера Казань. Полгода не могут найти себе разработчика, но всё равно держатся за то, чтобы все сидели рядом с ними в кабинете. Кажется, это даёт иллюзорный контроль?

    Н.: Именно — иллюзию контроля. Давай, наверное, начнём с определения удалённой работы. И здесь хочется не проводить сначала разницу между удалённой и не удалённой работой, а надо посмотреть на работу как таковую. На работе требуют разное. Есть работа, где ты просто приходишь, с 9:00 до 18:00 сидишь, что-то делаешь и в принципе – уже достаточно. Я называю этот подход «жопочасы» – вот ты пришёл и, соответственно, должен отсидеть. Всё. Больше никаких формальных требований нет. Особо хитрые работодатели могут придумать какой-нибудь нелепый KPI на минимизацию количества багов в проде. Или еще какой-нибудь бред. И тогда не менее хитрые программисты научатся его оптимизировать без полезной деятельности. И ничего не изменится.

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

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

    Н.: Совершенно верно, да. Результат – это не нечто большое. Результат – это что-то маленькое. Когда мы пытаемся достигнуть результата глобального, у нас появляются много маленьких промежуточных. И вот эти маленькие промежуточные результаты для нас тоже ценны и важны. И благодаря им мы видим понятный процесс, как человек идёт из точки А в точку Б, какие решения он принимает, какой код он пишет, какие фичи он видит дальше, в каком порядке он их делает. Мы получаем полную прозрачность. И нам в принципе становится не важно, где он находится, удалённо или не удалённо.

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

    О людях, медитативном программировании и двух главных принципах удаленки


    И.: Я знаю, что у вас вся команда распределённая. Создаётся ощущение, что ты очень сильно веришь в людей, а у другого техдира я читала, что он не верит в людей, а только в контроль и дедлайны. У тебя, кажется, позиция такая, что человек способен выполнить задачу самостоятельно без чётких постоянных инструкций и контроля с твоей стороны. Как ты думаешь: могут ли все разработчики работать в таком режиме? Какие люди справятся, а каким нужен постоянный контроль?

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

    Маленькую понятную задачу я целиком доверяю человеку и говорю: «Вот тебе задача на час или на два. Ты можешь её делать, как считаешь нужным. Вот наши критерии завершённости, вот тебе инструменты». И, соответственно, эти два часа его вообще никто не трогает, он волен делать всё, что угодно. Через два часа он приносит и говорит: «Вот мой результат». Или говорит: «Такое сделать за два часа никак нельзя, и вот почему. Я придумал вот такое решение на будущее».

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

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

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

    Это можно сделать при помощи подробного описания того, что мы делаем в документации. То есть создание единого языка, понятных требований, создание бизнес моделей и сценариев, понятных графиков и схем, принятых решений, вариантов использования и пользовательских сценариев. Это не то, что нам просто нужна вот такая-то фича, нет, а зачем она нужна, кто будет ей пользоваться, в каком случае, какие есть подводные камни в этой фиче. Документация создает полное понимание куда мы движемся. Скажу больше, из-за того, что у нас все эти маленькие задачки соединены воедино, получается такая “цепь из задач”, и разработчик может понять, с чего мы начали, куда идём, и в каком месте находимся.

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

    Моя единственная роль в этом всём – это просто контролировать направление, ну, и некую адекватность.

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

    H.: Совершенно верно. А теперь мы возвращаемся к удалённой работе. Почему мы, соответственно, выбрали этот вариант, а не вариант «офис». И ты сейчас точно подметила, что эти два пункта – являются ключевыми.

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

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

    И второй момент – документация. Хорошая документация может быть написана только тогда, когда она нужна. Потому что, если её пишут из-под палки и в неё не смотрят, не обновляют, она быстро становится плохой. Хорошая документация, например, в опенсорс-проектах как пишется? Она единственный источник того, как люди могут про этот опенсорс-проект узнать и воспользоваться. Если люди видят, что в документации что-то не работает, они создают задачку и говорят: «В твоей документации что-то не работает». Ты говоришь: «Ой, сейчас поправлю». Если человек сидит рядом, он просто тебя спросит: «А что делать-то надо в этой точке?». А ты вынужден ему отвечать. И в таком процессе документация хорошей не станет. Чтобы документация была хорошей, нужно, чтобы люди находились на расстоянии и не могли напрямую общаться.

    О системе оплаты удаленщиков и командообразовании


    И.: Забавно, получается, что людям, когда они находятся на расстоянии, получается проще включиться в проект, потому что они могут прочитать документацию, а в офисе приходится искать, кто начинал это писать, откуда этот кусок взялся и что это вообще значит?

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

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

    И.: Какие страхи и предубеждения у тебя были при переходе на работу с распределенной командой? Или их не было?

    Н.: Естественно, страхи были, и наши первые ребята, которых мы нанимали на удалёнку, работали по старой системе, то есть за зарплату. А когда ты платишь зарплату, тебе становится не всё равно. Потому что ты хочешь выжать максимум из того времени, которое человек тебе продал. У меня тогда было очень много сомнений и предубеждений. И вообще не было контроля. Скоро я понял, что в таком формате удалённая работа не работает.

    В итоге, мы тот эксперимент свернули. А теперь у меня есть скорее предубеждение к офису.

    Какой-то человек хочет, чтобы я находился где-то в конкретной точке на Земле, ограничивая мою свободу передвижения. А еще он хочет, чтобы я всё время тратил на него, ограничивая мою свободу деятельности. Странно, что многим людям такой вариант кажется нормальным.

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

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

    image

    И.: Как выглядит с твоей точки зрения правильно построенная удалённая работа? Вот есть некий разработчик, который готов работать на удалёнке, что происходит дальше?

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

    И хорошая удаленная работа выглядит точно так же. С чего начинается любое общение в опенсорсе? Разработчик создаёт задачку, говорит: «У меня что-то не работает», либо «Я не понимаю документацию», либо «Я хочу новую фичу». Ты смотришь, что нужно сделать для того, чтобы его удовлетворить. Далее идёт обсуждение, какие-то уточняющие вопросы, возможно, эта задача бьётся на несколько задач. А потом присылается код, который закрывает эти небольшие части. Код проверяется тестами и линтерами, происходит ревью. И потом просто релизится новая версия. Собственно, все.

    А весь искусственно созданный мир вокруг проектов, который есть сейчас из разряда «у нас 15 тимлидов, 6 проджект-менеджеров и два скрам-мастера», они нужны для того, чтобы выжимать больше из людей за те же деньги. Потому что проверить результат — никто не может при всей фикции важности и контроля. С ориентацией на результат все работает и без них.

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

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

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

    Н.: Конечно, нет. Я вообще против использования слова «команда» не по делу. Я считаю, что команда – это действительно что-то уникальное. Всё, что есть сейчас, традиционно на рынке – это коллектив, в лучшем случае. А в нашем случае это даже не коллектив, это просто набор людей, которые вместе делают один проект и зарабатывают деньги. Они не то, что не команда, они даже не знакомы. В основном сейчас слово “команда” используется как еще одна манипуляция людьми.

    И.: Интересно. По ощущениям, половина статей и выступлений об управлении распределенной командой о том, как сплотить эту команду, когда она в разных часовых поясах, говорит на разных языках, и как сделать эффективным взаимодействие. А для тебя этой проблемы вообще не стоит?

    Н.: Не стоит. Более того, я против того, чтобы людей насильно сплачивали. Я считаю, что очень многие люди переходят границы. Есть граница работы, а есть граница личной жизни. И вот по работе я готов общаться с разными людьми. Потому что это работа, я не всегда выбираю с кем общаться. Надо – значит надо. А вот когда мне начинают насильно пихать в нос людей, с которыми я не хочу общаться вне работы, типа «иди сплачивайся с ними». С чего вдруг-то? У меня есть свои собственные друзья, у меня есть своя собственная семья, зачем я буду тратить время на непонятно кого, когда я могу пообщаться с важными для меня людьми? Для меня такое абсолютно непонятно.

    «Нет», «может быть» и «да» — где искать разработчиков


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

    Н.: Да. И я стараюсь очень жёстко разграничивать те вещи, которые я могу делать, потому что я плачу за это деньги, и которые я делать не имею права, потому что я всего лишь плачу деньги.

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

    Н.: Действительно есть такая проблема. Люди видят то, что хотят видеть, и то, что они привыкли видеть. Если люди привыкли жить в индустрии, где их используют, обманывают, манипулируют, и кидают, то они это и видят. Если люди привыкли жить в обстановке доверия, в обстановке качественной работы и баланса, они видят это. Вопрос в том, что, к сожалению, у нас в индустрии первое преобладает над вторым.

    И.: Тебе не кажется, что на самом деле система, которую ты предлагаешь, решает одну из основных проблем разработчиков, которые говорят, что они действительно пишут код 15 минут в день? А в остальное проводят на митингах и выгорают, выгорают, выгорают…

    Н.: Конечно, я же её под себя делал! А я больше всего люблю писать код. Было странно, если бы я сделал систему, в которой я бы не мог писать код.

    И.: А могут ли у тебя сеньоры зарабатывать достаточно для своей жизни? И сколько часов в день они тратят, чтобы заработать столько же, сколько, например, в средне-статистической IT-компании своего города?

    Н.: Могут, но не все. Только те, кто много и качественно работает. Они могут зарабатывать очень много. Верхней границы нет и быть не может. А некоторые люди вообще ничего заработать у нас не смогли.

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

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

    Получается три группы: группа «нет» (это американцы и европейцы), группа «может быть» (это наши, Украина, Белоруссия) и группа «да» (это Африка, Азия и т. д.). Здесь вопрос конкретно моей реализации: за сколько я могу продать эту идею клиентам, и сколько они готовы платить. Опять же, мы работаем только с российскими клиентами. Если бы мы вышли активно на европейский или американский рынок, они бы платили больше, и эта проблема бы частично решилась. Но пока так.

    И.: Ты почти весь глобус описал! Насколько расширяется выбор кандидатов с выходом на международный рынок?

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

    И.: Скажи, а как ты ищешь разработчиков?

    Н.: Никак. Они сами приходят. Им интересно попробовать.

    P.S. Принципы работы Никиты могут вызвать и вызывают спорные мнения, но система показывает себя эффективной. Есть ли у вас альтернативный успешный опыт организации работы распределенной команды? Пишите в комментарии!

    А те, кто 2 октября 2019 будет в Казани, приходите на тимлид-завтрак, где можно будет обсудить данную статью: выразить все свое негодование или одобрение подходу Никиты, а также послушать 3 других истории про работу с удаленкой и аутсорсерами.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 19

      0
      Вот тебе задача на час или на два. Ты можешь её делать, как считаешь нужным. Вот наши критерии завершённости, вот тебе инструменты

      Почему вы своим программистам так не доверяете?
      Задача на час или на два это строк 30 в проде. Фантазии и свободы просто вагон.
        +2
        Задача на час или на два

        Да, некоторые постановщики так оценивают, иногда :)
        это строк 30 в проде

        А может и месяц-другой расковыривания со сменой базовой архитектуры…
        +9
        А второй способ называется «за результат»

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

        Только те, кто много и качественно работает. Они могут зарабатывать очень много. Верхней границы нет и быть не может.

        Вот тут манипуляция и уход от вопроса.

        Если так говорить, то и возможности заработка строителя или грузчика — тоже ничем не ограничены, ведь если за тонну разгрузки платят, скажем, 2000 руб, то что мешает тебе за день разгружать по 2 мегатонны и заработывать миллионы в день?

        Но это обман и манипуляция.

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

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

        А так же как вы оцениваете результат работы. Могли бы вы привести решение одной из задач, т.е. код, и указать сколько за него денег чел. получил?
          0
          Если брать чисто скорость написания кода — возможно и не большой разбег.
          А вот если с учетом долгосрочного проекта и набегающего увеличения сложности, связности кода и багов, то тут переделки в какой-то момент могут сожрать 90% продуктивности и плохой прогер от хорошего может отличаться и в 8-10 раз.
            0
            переделки в какой-то момент могут сожрать 90% продуктивности и плохой прогер от хорошего может отличаться и в 8-10 раз.

            Это не то что хороший/плохой, это разные специализации. И разница может быть не в 8-10 раз, а на 3 порядка. То же самое, кстати, актуально и для строителей — есть разные специализации. Как то если чел. занимается только сантехникой, у него построен процесс, есть современные инструменты, работает с лучшими материалами. Он будет работать на порядок быстрее и качественнее чем тот, кто «на все руки мастер». Второй тоже сможет, конечно, но займет и дольше и качество будет хуже.

            Если область сложная, как то реализация крипто-алгоритма по спецификации, то спец. выполнит на 3 порядка быстрее, т.к. не работающему в данной предметной области придется сначала вникнуть, что займет уйму времени.
              0
              Вот-вот.
              А вообще мне кажется это не масштабируемый вариант. Есть автор поста, и он скажем вполне адекватно может оценить время/стоимость задачи. И при этом готов нормально ее оплатить. В этом случае система работает.
              Но как только нам нужно будет увеличить группу в 10 раз, окажется что нужно еще минимум 4-5 человек которые будут помимо автора это делать, и тут человеческий фактор скорее всего сломает систему — или денег пожадничают, или с оценкой трудозатрат ошибутся, и в результате хорошие прогеры быстро разбегутся, а плохие останутся и окончательно избалуются, рисуя липовые часы, либо текучка начнется.
              Мне больше интересны принципы, которые от личности руководителя не особо зависят.
                0
                Вот-вот.

                Это умение правильно подобрать спеца под задачу. Но ведь под каждую задачу не будешь искать отдельного спеца… Даже если задачу А первый спец. выполнит на порядок-два быстрее второго, то может забуксовать на задаче Б, которую уже второй выполнит быстрее. Ведь опыт у всех разный, а когда что-то выполняешь во второй раз, с чем то уже сталкивался — то, понятное дело, времени займет меньше.
          +4
          Интервью, по ощущениям, очень похоже на пресс конференцию солнцеликого — в каждом вопросе интервьера либо уже ответ либо не сильно скрытое восхищение. Поэтому и не было неудобных вопросов. Поэтому и неинтересно получилось.
            +4

            И даже в таки условиях много "интересного" вылезло:


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

            Хорошая схема для проекта, но не очень — для желающих в нём поработать.
            Особенно смутили намёки про то что люди часто меняются (и архитектура проекта под это заточена) и отношение как к коллективу, а не команде — очень и очень нехороший маркер для работников. Звучит как «выжимать из тех кто пришёл максимум, а потом выбрасывать, потому что есть ещё легион на замену».
            Эффективный менеджмент как он есть.

            Так же, про декомпозицию на маленькие задачи (2 часа?!). Когда проект большой и задачи сложные, то для управления и развития требуются специалисты, которым быстрее реализовать задачу «на два часа кому то там», чем даже написать эту задачу. Совсем другой масштаб. И такое не отдашь тому, кто не погружён или просто по документации.

            Я, всё-таки, за то, что бы проект делался командой. Удалённой или нет — не важно. Особенно проект требующий глубокого погружения — люди создают большую логику и понимают как она в целом и по частям будет работать, и делигировать части этой логики — большой риск. Да и специалисты которые это делают — стоят дорого…

            Как то так.
              0
              Ну, требование писать документацию так чтобы без присутствия тебя лично с нею разобрался бы любой- это вполне здоровое требование, причем характерное и для других сфер, например от нас так требовали вести замеры в лабораториях. Просто потому что через месяц ты уже сам не вспомнишь, что тут накалякал.
              Это просто обеспечивает высокое качество кода и документации.
                0
                А я что то писал про то что против документации?
                Я всегда ЗА документацию, конечно.

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

              Ну это проблема именно в этих «кто-то». Ситуация на рынке IT как в индийском поезде, кодерков выше крыши, бери — не хочу. И это миддлы и выше. Посему тут проблема очень проста, сформулирую.

              Галера не хочет платить хорошую зп хорошему разработчику, жмотится и старается дать поменьше. Как альтернатива — выдвигает за нормальную зп неадекватные требования, возможно, ищет супер-пупер фуллстэка (чтобы не платить двум узким спецам). Ищет сеньора на мидловскую позицию, при этом не желает вырастить из крепкого разработчика уровня middle+ хорошего сеньора за год-другой. Чаще всего таким грешат непродуктовые конторки (это и понятно), но, к сожалению, и в продуктовых эти грешки сплошь и рядом.

              Так что делайте выводы, господа. А найти хорошего разработчика middle \ middle+ не проблема за 1-2 недели.
                0
                Судя по тексту, это получается какой-то фрилансерский подход, когда у тебя есть задача и тебе за нее платят, а уж каким образом и сколько ты ее будешь ковырять сугубо твои проблемы.
                Не напрягает ли сотрудников такой подход? Многие ищут постоянную работу как раз ради стабильности, а тут стабильности то и нет: можешь заработать горы, упахиваясь в ноль, а можешь остаться ни с чем? Какое тогда отличия работы с вами от фриланса с точки зрения сотрудника?
                  0
                  Всегда один заказчик, который ставит задачи
                    0
                    Все упирается в адекватность того, кто ставит задачи. Оценивает нормально, платит нормально — будут хорошие кадры. Чуть-чуть испортился — и все пошло в разнос.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Вот-вот у меня к масштабируемости тоже очень большие вопросы. Такое держится на одном человеке, и когда надо расширится за пределы того обьема, который данный человек может вытянуть — нанятый второй запросто пускает систему под откос.

                      А как бы так выстроить требования, чтобы хорошо получалось в любом случае, с или без талантливых лидов — очень интересный вопрос. Когда-то Форд поставил производство авто на конвейер, где бы найти способ штамповать кадры…
                      0
                      Какая то сказочная история где и ЗП в разы выше российских, и цены для заказчика в разы меньше московских, и задачи на два часа.
                      Воплощение индусо-муравейника в чистом виде какое-то.

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

                      Самое читаемое