Пользователь
0,0
рейтинг
24 декабря 2014 в 00:54

Управление → freelance — you're doing it wrong!

Доброго времени суток уважаемые хаброжители, меня зовут Юра, и сегодня я поведаю вам о проблемах высокотехнологичного отпрыска удалённой работы — фриланса, а именно о разработке мобильных, десктопных и вэб-приложений, вёрстке и дизайне. Работаю я в этой сфере достаточно недавно, буквально с 2008го, и опыта хорошего и плохого у меня накопилось достаточно много. Цель данной публикации — показать разницу между простыми сотрудниками и фрилансерами, а также — показать основные организационные проблемы, которые возникают при разработке и проектировании программного обеспечения. Я надеюсь, что этот пост поможет прояснить некоторые производственные моменты, которые могли бы быть не совсем очевидны для разработчиков и их руководства.

Суждения в данной статье субъективны — сплошная концентрированная «отсебятинка».
Они основаны на моём личном опыте и опыте людей с которыми я общаюсь.

Далее многабукф


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

Основными причинами конфликтов и организационных проблем являются


  1. Компенсаторные процессы психологических проблем


    • Я хочу быть самым главным и/или самым умным...

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

    • Я хочу подчиняться...

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

    … а не разрабатывать качественные, конкурентоспособные и надёжные продукты


    Конечно, когда обе группы людей находят друг друга — они работают некоторое время, и даже способны выпускать продукты. Именно поэтому на территории СНГ не было выпущено вменяемых стартапов о которых можно было рассказать внукам, а большинство людей мигрируют — там часто принято решать проблемы интенсивно, а не игнорировать их, или попусту наращивать персонал, и само понятие проблемы по определению совсем другое. Впрочем, у нас тут и стартапом принято сейчас обзывать любой молодой мелкий бизнес в рунете, так что дожились, товарищи, дожились… В принципе, есть исключения, но можно посчитать на пальцах: Яндекс, ВКонтакт, Одноклассники да Mail.ru что-то в предсмертных конвульсиях задёргалось, да что-то делать начало за последние 5 лет. Это всё конторы, для которых свойственно интенсивное решение большинства проблем, и компенсироваться там сложно, из-за этого тоже возникают достаточно глупые ситуации.

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

    <rage>
    Как пример, могу привести групповую «помощь» в рамках среднестатистического «тренинга» или психокульта, как его принято называть в Штатах и Европе. Вместо того чтобы решать проблемы конкретной группы индивидов, им внушают что у них этих проблем нет, они перестают компенсироваться, и в следствии работают с удвоенным энтузиазмом, о реальном выхлопе на первых порах речи не идёт. Когда у обезьянок под кокаином глазки немного сужаются — они просят ещё. В общем это зависимость от примитивных иллюзий, которые всего лишь замедляют, но не прекращают компенсаторные процессы. Вулкан ещё будет бушевать, и ещё как разозлится…

    Бывают исключения из этого правила, но обычно никто не проводит аудит психологических тренингов и работы психолога в рамках конторы. Тренинги, чаще всего, — требования каких-то иностранных начальников.
    </rage>

    1.1 Коммуникационные проблемы


    Чаще всего коммуникационные проблемы возникают из-за
    • Неадекватной самооценки и неадекватных представлений о людях
    • Разделения на «свой-чужой»
    • Несоответствия ролей в коллективе
    • Отсутствия ресурсов — времени или денег

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

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

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

    Часто приходишь в коллектив и не понимаешь, чего люди свой хлеб едят — модель БД не нормализирована, лапша из «перестыкованного полтергейста» приправленная парой «божественных объектов» с «синглетонизацией» всего, тобой пытается руководить человек, который очень фанатично относится к своему творению и не способен выдержать какой-либо критики. Очень уж руководить ему хочется, а те, кто выше даже не проверяли его компетенции. Поэтому, я просто перестал работать с РНР проектами — процент дилетантов слишком большой.

    Роли в коллективе могут меняться по мере реализации проектов и это можно использовать как дополнительное средство мотивации и укрепления сотрудничества.

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

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

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

    Люди не склонны проверять на практике навыки фрилансера о котором «кто-то сказал хорошо», либо который оставил хорошее впечатление человека способного «всё сделать за деньги», а таких на самом деле не бывает. Нужно помнить о потребности развития и пытаться понимать какой именно опыт нужен конкретному исполнителю, и зачем он здесь?.. Сделать шаблонный проект, срубить денег, и побежать дальше?.. Но кому нужны такие продукты? Они нужны жадным людям, которые в меру своей недоразвитости верят в иллюзию быстрой прибыли от публикации продукта любого качества, а что потом?.. А потом объявления в стиле «доделайте то… доделайте сё… за 1000 руб. без документации и тестов». Выполняют подобные проекты люди, которые застряли на каком-то одном инструменте и не способны развиваться далее, как разработчик. Впрочем, часто они не способны развиваться и как личность.

    Если люди не могут нормально общаться в онлайне, в живую они тоже не смогут этого делать.

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

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

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

  2. Отсутствие контроля качества


    • Нет выработки требований

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

      Понятно, что 80+ страниц ТЗ по ГОСТу для автоматизированных систем никто со старту не напишет, но требования к проекту могут меняться в процессе исследования рынка сбыта и целевой аудитории. Так что выработка требований — отдельный процесс разработки требующий прямой коммуникации с заказчиком и/или руководством, его нельзя осуществлять только одними лишь менеджерами, тут полезна любая точка зрения не только дизайнера или программиста, а может даже и ваших родственников, чем больше взглядов на продукт и задачи, которые он решает, тем точнее требования. Обратная связь от целевой аудитории является более релевантной, чем первоначальные требования, что приводит к последующей их эволюции. Обычно проходит 2-3 цикла выработки требований прежде чем они формулируются окончательно.

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

      Вот так обычно проходит выработка требований


      Зачем кому-то рисовать семь красных линий?
      Какую задачу пытаются решить таким образом?
      Для какой целевой аудитории предназначен подобный функционал?

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

    • Нет учёта выработки персонала

      Для руководства всегда нужно держать «руку на пульсе», и сложнее всего с внедрением средств контроля выработки персонала, не только фрилансеров, но и простых офисных и удалённых работников, понятное дело, больше 6ти часов в сутки никто в IDE'шке не протянет, а даже если и протянет — наверняка зря. Но даже эти 6 часов уже о чём-то говорят. Вы можете спокойно запустить у себя какой-то Harvest или RescueTime — результаты довольно интересные. Отлынивают все, а руководство — больше всех. Цифры — мотивируют.

    • Нет тестов

      Для меня лично, печальнее всего частое отсутствие приёмочного тестирования, для проектов в 1-2 тела — это может сэкономить достаточно много времени. Щёлкаешь руками — себя не уважаешь. Приёмочные тесты также являются хорошим индикатором продвижения работы для руководителей. Если приёмочные тесты это must have и без них обойтись довольно сложно, то от функциональных (модульных), интеграционных и нагрузочных чаще всего приходится отказываться до первого релиза.

      Отсутствие тестов, это
      • экономия времени и ресурсов сейчас (около 20%), но большие затраты в перспективе, естественно с экспоненциальной зависимостью
      • крест на поддержке продукта и BusFactor = 1
      • неспособность руководства думать о перспективах продукта, и давать гарантии клиентам.
        Скорее напротив, подобного рода руководство склонно делегировать ответственность сторонним вендорам, создавать vendor lockin и довольно замысловатые зависимости с кучей побочных эффектов. Хотя на самом деле, чем больше готовых неконтролируемых структур используется для поддержания работоспособности продукта — тем больше риск отказа его компонентов.

    • Нет репозитория

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

    • Нет аудита существующих решений

      Нужно понимать сколько людей — столько и взглядов на проблему, и это хорошо. Аудит существующего решения в рамках конторы может принести много новых плодотворных идей и решать достаточно большое количество проблем. Чем больше человек «проходится» по коду — тем он чище, и как минимум не будет спагетти-кода, bloatware и pattern-hell.

    • Нет рефакторинга

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

      Разработка программного обеспечения — это рекуррентный процесс. Вообще по ГОСТу для автоматизированных систем всего 2 итерации: эскизный и технический проект, потом идёт разработка проектной документации. Хотя на практике обычно нужно 4-5 прежде чем продукт можно будет спокойно использовать и поддерживать. Для рефакторинга обязательно наличие тестов и репозитория.

    • Нет аудита ресурсов и соответствующей оптимизации расходов/доходов

      Люди не умеют получать прибыль с продукта, оценивать риски, и тратить всё с умом. Нет смысла закупать 100 серверов по 64Гб памяти в каждом и с б/у винтами по 500Гб в RAID-10, когда у проекта всего три десятка клиентов. Нет смысла экономить на организации процессов, но любые решения, принимаемые без обсуждения и аудита со стороны, подразумевают под собой какие-то риски, нужно брать эти риски в расчёт, иначе деньги пускаются «на ветер».

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

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

  3. Отсутствие отработанной методологии разработки


    Я недавно писал почему SCRUM не очень подходит для постсоветского пространства. И причиной тому как раз-таки психологические проблемы и компенсаторные процессы. Люди заменяют процесс анализа обсуждениями, а предположения принимают за факты. Это тоже различные случаи когнитивных искажений при принятии решений.
    Получается «Собрание ради собрания», «Код ради кода».

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

    Хватит орать «у нас тут Agile», Agile это четыре забавных правила, к которым все хотят стремиться для повышения качества ПО и счастья разработчиков… Agile методологии — это набор абстрактных методов, которые можно использовать для достижения целей Agile. Но это не означает, что они будут работать для вашего коллектива.

    Нужно начинать с чего-то малого — возьмите V-model и адаптируйте его к Lean c Kanban'ом.
    Вместо того чтобы строить высоко-рекуррентные процессы, выполняйте всего 2-3 задачи одновременно по принципу «разделяй и властвуй», а потом, когда закончите 2-3 проекта, уже можно играться со всякими SCRUM'aми. Из документации достаточно пользовательских историй, описания модели БД, описания сервисов в SOA, тестов, и схемы API в ком-нить Swagger'e или JSON-WSP.

  4. Организационные антипаттерны


    • Аналитический паралич — выработка абстрактных спецификаций ставится выше разработки даже самой сырой реализации продукта. Выработка требований и реализация — рекуррентные процессы, и пытаться «проглотить слона не пережёвывая» довольно глупо.

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

    • Дойная корова — деньги должны приносить деньги, не стоит всё «проедать», тратьте прибыль с проектов на реализацию более масштабных. Нет ничего вечного.

    • Непрерывное устаревание — портирование плохо структурированного legacy кода из-за смены условий или требований к проекту заканчивается ужасными расходами и задержками сроков. Это, наверное, наиболее типичный антипаттерн для существующих костыльных проектов в которых «зачем переписывать, а мы что зря свой хлеб ели?».

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

    • Разработка комитетом — проектирование без централизованного и компетентного руководства. Такое встречается в 80% проектов в СНГ и в Европе. Много народу собирается и «тыкают пальцем что популярно, туда и двигают», ничего не меряют и не анализируют, принимают решения в стиле «если это использовалось в большом проекте, и оно там работает, значит это будет работать и у нас». В итоге получается «много, но дурного» и bloatware.

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

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

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

    • Vendor lock-in — отсутствие адаптеров для различных вендорных решений, очень сильная связанность с их функционалом. Как говорится, «никого ещё не уволили за покупку софта IBM». Особенно это касается решений на основе Oracle и Microsoft — перейти на OpenSource потом бывает довольно сложно.

    • Грибной менеджмент — отсутствие вменяемой выработки требований с последующим требованием решения различных задач, которые непосредственно к проекту не имеют большого отношения и быстрее всего будут переписываться наново. Случается, из-за бездарности руководства, которое не способно рассмотреть и принять любые варианты реализации кроме своих собственных. Обычно подобное потом ещё нужно 2-3 раза переписывать и покрывать тестами. Мой самый ненавистный случай.

    • Одна знающая голова — это когда один человек в проекте более-менее разбирается во всех процессах и принимает аргументированные решения, а все остальные просто наблюдают. Без нормальной документации это BusFactor == 1. Если ещё человек раздувает свою значимость, то он превращается в антипаттерн «рыцарь в сияющих доспехах», даже когда он принимает довольно глупые решения все продолжают кивать головой в ответ.


  5. Архитектурные антипаттерны


    Я не хочу копировать вики или лурку. Но в общем, проблема в том, что люди застревают на определённом этапе развития и инструментария, не отрабатывают даже самые распространённые шаблоны проектирования. Я уже не говорю о разнице между proactor'ом и reactor'ом, или о таких монстрах как CQRS-ES. Но пару книжек о шаблонах по любому надо прочитать и сразу же реализовать всё на практике и покрыть тестами, иначе толку реально мало.

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

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

    Если вы попадаете в проект, то первое на что стоит обратить внимание это
    • Нормализация модели БД — пятая/шестая форма это уже MustHave, а не «третей формы хватит всем» как и 640Кб оперативки
    • Менеджмент зависимостей — Composer / pip / Bundler / Gradle / npm / bower… это то что должно быть в любом проекте.
    • Непрерывное внедрение — если проект раздроблен на кучу мелких сервисов, нужно постоянно тестировать их взаимодействие и разворачивать тестовые сборки.
    • Разворачивание инфраструктуры и мониторинг — возможность настроить сервер для определённого сервиса за минимальное время очень ценна. Сейчас немного поменялись тенденции в мониторинге инфраструктуры — люди слезли с Zabbix/Nagios на Kibana и индексируют логи с logstash/fluentd в ElasticSearch. Мониторинг является средством обратной связи для осуществления горизонтального масштабирования и определения недостатка существующих ресурсов.
    • Профилирование решения — мерить скорость работы и потребление ресурсов отдельных модулей нужно постоянно. Не думайте, что если у вас есть проект на ноде и вы перепишите критические участки на сишку это будет быстрее — меряйте, меряйте и ещё раз меряйте.


Как же это всё обычно происходит?


Рассмотрим круговорот разработчиков в природе, основные причины миграций флоры и фауны, а также наиболее распространённые инструменты и задачи для каждого из этапов.

Концентрация «отсебятины» очень сильно «зашкаливает», можете просто прочитать пункт «3» из этого списка и перейти к его концу, если влом читать.

1 Базовые знания технического ВУЗа неподкреплённые реальной практикой

На уровне третьего курса Компьютерной Инженерии (КИ), Компьютерных Наук (КН) и Программной Инженерии (ПИ) или даже Автоматизированных систем управления (АСУ) и Телекоммуникационных систем (ТС), к сожалению, большинство преподавателей не объясняют в чём же разница между родственными кафедрами, даже если больше половины основных предметов совпадает. В случае с «некомпьютерными кафедрами», которые делают упор на проприетарные решения, Vendor Lockin и пустую теорию, ситуация довольно прискорбна — люди чаще всего много знают, но применить на практике, и адаптировать к существующим процессам разработки, свои знания не могут. Большая часть абитуриентов поступает «потому что престижно», а не потому что «я знаю, что я хочу делать, и как я помогу этим другим», и это довольно прискорбно.

Бывают и исключения из правил, и особо фанатичные школьники пилят Сишку с самодельными ATMEGA8 платками (TQFP, а не DIP), ЛУТ'ом, и простыми 0805 SMD компонентами. Arduino — часть POP-культуры, да и довольно дорогая, так что обычно проходит мимо. А уже к 1-2 курсу подобный контингент легко и непринуждённо осваивает Cortex-m0, Cortex-m3 и даже Cortex-A5 A9 и ARMv7 ARMv9. В таком случае часто развиваются навыки администрирования и приход к OpenSource софту возникает в возрасте 15-16 лет. Чаще всего склоняются в сторону ArchLinux или же более дружественных Ubuntu/Mint (если у них были деньги на Arduino). Если же этот период не был пройден «в школе», то он затягивается до 3его 4го курса университета, а заканчивается всё работой в каком-то более-менее престижном аутсорсе.

Чаще всего школьники и студенты идут в сторону вёрстки и разработки простых сайтов на популярных CMS, естественно особым качеством или стабильностью подобные решения не отличаются, но определённую целевую аудиторию они имеют. Навыки администрирования чаще всего на уровне «могу поставить LAMP чтобы работало».

В принципе у школьников все это протекает довольно хаотично, и что попадёт под руку, то и будет прочитано…
Первым школьным холиваром является «лучший язык программирования», или «лучший фреймворк/СMSка». К сожалению подобным вопросом задаётся очень большое количество дилетантов. Правда такова, что идеального решения нет — пробуйте всё, тогда вы сможете подобрать какой-то один более подходящий инструментарий для конкретных условий и задач определённого проекта. Верить, что ваш любимый SomeRandomName фреймворк подходит для всего — наивно и достаточно рискованно для заказчика, это детский антипаттерн «golden hammer», и через это все проходят рано или поздно.

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

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

Обычно люди начинают реализацию первых проектов на
  • Wordpress / Drupal / Joomla
  • C# WinForms ASP.NET
  • C++ Qt
  • Python Django
  • PHP Yii / Symfony2 / Zend / CakePHP / Kohana
  • html5/css3/js jQuery Angular
  • node.js Express.js / Sails.js + mongodb

А вот с java сейчас почти никто не начинает :(
Ну по крайней мере я как-то не заметил за последние 3 года, хотя язык достаточно простой.

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

С этого места начинается фриланс, возможно, даже удалённая работа.

2Проект, где есть чему поучиться

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

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

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

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

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

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

Из инструментариев сейчас очень популярны:
  • Angular React и сборка фронтенда на основе gulp + browserify/webpack
  • node.js решения на основе express.js / sails.js, и socket.io / sock.js для коммуникации
  • Play2 и Typesafe stack, иногда Xitrum
  • ElasticSearch и Kibana c logstash/fluentd

PHP / Python / Ruby на сегодняшний день плохо подходят для современных требований рынка, с его реактивностями, RESTful сервисами, богатым фронтэндом, push-нотификациями на сайты и в мобильные приложения. Исключением являются порты под JVM, типа jRuby с их оптимизированным компилятором на уровне Project Graal. Вот про производительность Jyton'a ничего не знаю, так что ничего не могу сказать. Groovy тоже сейчас довольно шустрый, но вот от J2EE сервлет-бутербродов я испытываю глубокое отвращение.

В десктопе сейчас в принципе ничего нового, Qt да .net правят балом.
Java и Air всё реже используется для десктопа, хотя я лично в восторге от JavaFX2.

Люди, которые начинают разрабатывать мобильные приложения, обычно начинают не с них, это либо различные J2SE, а не J2EE, Java проекты после которых переходят на Android, либо это различные сайтики на джанге, рельсах и ноде после которых переходят на Objective-C / Swift и разработку под яблоки. Поэтому именно с этого момента начинается разработка мобильных приложений, у людей должен быть средний достаток чтобы стабильно начать разрабатывать под различные мобильные платформы, да и навыков в дэсктопе и вэбе должно быть достаточно много.

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

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

3Проект «мясоперерабатывающий цех»

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

Люди, которые работают «за еду» не способны видеть перспективу, их главной задачей является получение любого дохода, а не предотвращения головной боли заказчиков/руководства и в итоге своего собственного. Их развитие быстро останавливается, они становятся ригидными, и выпускать качественные продукты чаще всего не способны.

Сюда попадают люди у которых не было примера как делается «хорошо», или люди, которые «хотели хорошо, а получилось как всегда». Работать они могут долго и упорно, и стабильно получать свою зарплату, как говорил Витя «главное стабильность!» ну, а качество оставим на потом.

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

В несформированном коллективе защитной реакцией будет отторжение любых нововведений с последующей полной изоляцией. Естественно об этом никто прямо не скажет и денежку платить будут, но искать момент для «запекания белой вороны» будут все, кому не лень. В лучшем случае всё заканчивается сценарием «детей в песочнице»: «вот он плохой, давайте с ним играть не будем», без какого-либо обсуждения и принятия последующих решений. Правда обычно этим людям уже под 30тник… Если быстро не разобраться с отношением, и не принять соответствующих решений, возникает «грибной сад в дымоходе».

Для подобных проектов характерна статическая ставка в час, не зависимо от компетентности разработчика или его навыков и роли в проекте, менеджеры или тимлиды могут получать в 1.5-2 раза больше, просто потому что они «выше», а не потому что у них опыта больше. При этом их вклад в проект довольно сомнителен.

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

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

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

Одним из моих самых любимых частных случаев подобных проектов являются «квазистартапы с ложноножками».
Как говорила одна барышня с Luxoft'a, на одной средненькой презентации три года назад, «у кого нет стартапа, тот — лох» (дословно). Ух как же мне тогда хотелось врезать по… правда меня там тогда не было :( Учитывая примитивность, а иногда и полное отсутствие корпоративной культуры luxoft'а в то время, подобное поведение их сотрудников меня не удивило. Это сейчас они начали работу с сообществом, и разработку корпоративной культуры — поняли, что это не только «котов дрессирует», но и клиентов привлекает. Было даже пару статей негодования их руководством на хабре — опять же у людей просто не было мотивации и возможности для личностного и профессионального развития. В любом случае я рад что произошла ротация, и они решили большинство своих организационных проблем, хотя и «ритуалы посвящения» с некоторыми компенсаторными процессами никуда не делись.

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

Стандартные вопросы, которые не решаются в «квазистартапе»
  • Целевая аудитория и позиционирование — чем уже позиционирование одного продукта, тем проще управлять его сообществом и осуществлять поддержку. Никто же не мешает выпустить 10ток продуктов под различные задачи и целевые аудитории, как это было с atlassian и salesforce. Очень много сервисов в РФ тянет к Bloatware и «параноидальному-фьючеризму». «Проект будет полезен всем, и он лучше всего, что есть на рынке» — этот примитивный предрассудок я слышу очень часто.
  • Основное отличие от конкурентов и привлечение клиентов — к большинству проектов применяется свойство «очередной», и для целевой аудитории не понятно, чем он лучше того, к чему привыкли. Учитывая общую ригидность рынка сбыта, это очень критично для РФ и СНГ в целом, но не так критично, к примеру, для рынков США и Европы.
  • Вертикальное/горизонтальное масштабирование по требованию и мониторинг — часто возникает волна посещаемости, которая в 10-20 раз выше ожидаемой, нужно иметь возможность добавить быстренько железа и снизить нагрузку. Иногда перспективные проекты теряют достаточно большое количество существующих и потенциальных пользователей. Был такой сервис «спрашивай.ру» когда-то в 2009ом — он очень быстро лёг от большего количества школьников и студентов, после чего количество пользователей снижалось экспоненциально.
  • Долгосрочная поддержка и профилирование — нужно учитывать, что если вы разрабатываете продукт на 5-10 лет минимум, то и используемые инструменты этого продукта должны прожить столько же и сохранить обратную совместимость. В случае с Rails / Node.js / PHP / Python приложениями это довольно сложно. И опять же мерить, мерить и ещё раз мерить скорость работы и потребление ресурсов всего и всея.

Если эти вопросы не решены, значит проект точно ждёт смутная перспектива.
Хотя не факт, что в нём вообще есть кто-то, кто способен представить, что будет через пару лет, или даже через месяц.

Опять же люди могут бродить по «цехах» недосайтов на CMS'ках и «Битриксах» достаточно долго, и это хороший опыт.
Хуже всего если они там подолгу задержаться. Смена перспективы очень сильно способствует личностному и профессиональному развитию, но и менять работу слишком часто очень плохо — нужно хотя бы что-то доводить до конца. Петлять нужно, когда возникает «проблема» в английском значении этого слова — это что-то непреодолимое, конфликт, который нельзя разрешить, а всё остальное препятствия на пути реализации продукта.

Очень весело с менеджером-подкидышем, который стоит на пути общения с заказчиком и последующей выработке требований под предлогом «я всё переведу на понятный язык». Естественно их вклад в развитие самого проекта очень сомнителен. Обычно подобные особи не обладают какой-либо компетентностью в плане контроля качества и долгосрочной поддержки, не могут задать правильные вопросы, и являются «испорченным телефоном». Получается и выработка требований затягивается, и разрабатывается абстрактный продукт, который может совсем не иметь никакого отношения к тому, что хочет заказчик. Вместо того чтобы формулировать конкретные задачи и сценарии пользования — оперируют «хотелками» и «розовыми пони», потому что кошелёк толстый и у кого-то слюнки капают. Тут плодят «незаменимых» и будят в 3 часа ночи потому что что-то «отвалилось». Развивать навыки сложно, а иногда и вообще невозможно.

Если заказчик/руководство в «мясоперерабатывающем цехе» играют в «самого главного и самого умного», то про какое-либо развитие и речи быть не может — это люди которые избегают проблем, они их не решают, не получают опыт, и соответственно не развиваются. Это очень хорошо прослеживается при выбросе эмоционального напряжения — подавленное сознание само выплёскивает наружу наиболее укоренившиеся образы в подсознании, и люди, сами того не осознавая, проецируют то, что внутри думают о самих себе на окружающих (примитивная проекция — крутой кот, он у меня «очень злой и недоволен происходящим»). Задачу развития они заменили задачей получения материальной выгоды. Мало того что мозги пилить будут «как жить надо», так ещё и любые задержки в выплатах будут объяснять вашей какой-либо «несостоятельностью». Если такие умные — пускай сами делают, чтобы языком чесать — много мозгу не нужно. Пытаться объяснить что-либо — бесполезно, так как любые предложения или критику в свою сторону они будут либо отрицать, либо в подсознании просто возненавидят себя, и эта ненависть будет успешно проецироваться на вас. Обычно я таких просто игнорирую и приостанавливаю любое сотрудничество несмотря на любые договорённости — мои нервы стоят дороже. Да, «я плохой» потому что не пытаюсь расставаться с заказчиками «по-хорошему», но в этом случае — это нереально. Быть для всех хорошим — не получится, это заведомо очень ущербная позиция. Если у вас есть решение этой проблемы — пишите в личку. Психологи советуют просто посылать, а я обесцениваю — это подсознательная блокировка и подавление чувства злости, которую я и компенсирую написанием этой статьи.

Между сменой проектов чаще всего люди ищут новые методы решения проблем на ихнем предыдущем месте работы, и тоже возвращаются к обучению и исследованию существующих подходов и инструментов. Правда, вероятность что они опять попадут в такое же весёлое место слишком высока. Это всё будет продолжаться до тех пор, пока они не начнут анализировать поведение персонала, существующие организационные проблемы и решения, которые принимает их руководство. Если им это удаётся, они после «просвещения» часто попадают в нормальные проекты, но это вопрос удачи.

4Мелкий стартап или аутсорс

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

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

Главное тут не застрять.

5Становится дрессировщиком котов

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

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

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

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

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

6Открывает свои мелкие проекты

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

Ну это я про идеальные варианты, их очень мало…

А обычно кто-то тратит кучу денег с горящими глазами без какого-либо опыта организации процессов разработки, аудита и контроля качества продуктов. Причём такое случается, по моим субъективным оценкам, где-то в 90% всех проектов с которыми мне приходилось работать.

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

1Учиться тому чего не хватило

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

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

И все тянутся к Agile как к «универсальному оружию» для отстрела «вольных птиц» стартапов.
Опять же ригидность и компенсаторные процессы пачки народу не позволяют просто «взять и внедрить». Так что появляются гневные посты на хабре что "Scrum не работает", а я скажу, что он работает только в случае со здоровыми коллективами в которых BusFactor это хотя бы 20% персонала — придавило автобусом, и никто не заметил. Но и метрики обычно используются очень упрощённые и «наигранные», которые не имеют никакого отношения к процессам разработки и проектирования.

А в чём разница между фрилансом и полноценной удалённой работой?


Основным преимуществом фрилансера перед простым рабочими является возможность интенсивного накопления опыта — он может наблюдать «как не нужно делать», и соответственно развивать свои профессиональные навыки. В фриланс идут не потому, что там тепло и уютно, а потому что в офисах стало невозможно разрабатывать перспективные продукты. Либо идут достаточно развитые личности способные осознать существующие проблемы индустрии и как это всё способствует их развитию (никак). Фрилансеры становятся «мастерами» просто потому, что им приходится сталкиваться с огромным количеством проблем, с которыми не могут столкнуться простые рабочие… Конг-фу в дословном переводе — «тяжкий труд», а что может быть тяжелее, чем осознавать количество проблем, которые свойственны ИТ рынку, и пытаться делать своё дело лучше чем вчера?

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

Простые правила работы с фрилансерами
  • К фрилансерам обращаются, когда всё плохо, а не, когда всё хорошо, и квалифицированный специалист с недюжинным самообразованием должен получать соответствующее вознаграждение. Не стоит относиться к ним, как к людям способным решить любую проблему за деньги, нужно понимать, что у них тоже есть своя мотивация раз они взялись за работу, и важно, чтобы они её не потеряли.
  • Если фрилансер не способен дать гарантии выполнения своей работы или гарантии долгосрочной поддержки без его непосредственного участия в проекте — это не тот, кто вам нужен.
  • Нет столь универсального средства которое решало бы любые поставленные задачи – люди, которые так думают просто перестали развиваться.
  • Нет человека способного работать над всем в одиночку без сторонней мотивации, и вам нужно будет позаботится о её наличии.
  • Вера в самоорганизацию слишком наивна, у дисциплинированных людей, способных организовать свою работу, должны быть на то причины — просто «взять и организоваться» не получится, а что может мотивировать к организации труда больше очередной ошибки или провала?
  • Для фрилансеров и удалённых сотрудников важно общение, доверие и равенство. Их отсутствие выльется во внутреннее напряжение, которое будет компенсировано не самым приятным образом.
  • Нельзя просто взять переделать фрилансера в удалённого сотрудника — старые неудачи и привычки миграций очень глубоко проникают в мозг. Чтобы от них избавится нужно сделать его полноценной равной частью коллектива, а на это нужно время.
  • «Голодные» всегда требуют предоплаты, и быстро её «проедают». Не ловитесь на этот крючок — вам ведь ещё нужны гарантии выполнения работы?.. Лучше возьмите любого сотрудника или фрилансера, может быть двух, и попросите подтвердить свою состоятельность к оплате, и сказать всё, что они о вас думают. Чем больше о вас могут рассказать плохого — тем лучше, покажите, что вы способны учиться на своих ошибках, и требуйте того же от ваших сотрудников и партнёров.
  • Работа не должна быть хобби. Когда подобное происходит — она очень быстро надоедает и перестаёт приносить удовлетворение из-за обязанностей. Люди очень быстро «выгорают», а хорошего способа отдохнуть у них не остаётся.
  • Фрилансерам бывает очень сложно сохранить цикличность процессов разработки:
    Анализ/Исследование -> Проектирование -> Реализация -> Измерение -> Оптимизация -> Планирование.
  • Все допускали ошибки, прежде чем работать с кем-либо — нужно расспросить о предыдущих провальных проектах и конфликтных ситуациях, не бывает такого, чтобы всё было хорошо и все всегда были довольны. «Плюсики» на биржах совсем не показатель.

А как же вёрстка и дизайн?


Всё довольно печально.

Как люди верстали в 2008'ом, так и верстают: куча вложенных селекторов и div'ов / span'ов, раздутая CSS объектная модель, отсутствие какого-либо намёка на семантику разметки. Берём в HTML5 разметке меняем DOCTYPE, и в принципе получаем тот-же XHTML, что и был 7 лет тому назад. Я вообще поддерживаю разделение вёрстки и разметки — стили отдельно, структура отдельно. У меня по этому поводу достаточно много разногласий с любителями БЭМ'a, ну типа таких. Для себя я выработал правило: «если в разметке страницы больше 5ти div'ов / span'ов или есть вложенные — это не HTML5».

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

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

Задачи юзабилити — это задачи промышленного дизайна, а не художников-иллюстраторов, которые рисуют красивые иллюстрации, или графиков, которые рисуют иконки. Главный предрассудок оценки UX руководством: если выглядит красиво, то это должно быть удобно для конечного пользователя, и информация воспринимается просто. На самом деле, если сравнивать чёткость выделения контекстов и количество информационного шума, то у большинства промо-страниц обычно 2-3 контекста и возможны 3-4 источника шума, чаще всего совсем не выделяются контексты для формирования неявных намерений пользователей. Некоторые особенности пользовательского опыта совсем не очевидны и выявляются только в процессе проведения сплит-тестирования.

Основные изъяны в большинстве существующих дизайнов
  • Несформированная паллитра — 50 оттенков серого, и прочее «пипеточничество» фотошопа без какого-либо намёка на знание колористики или умение пользоваться Kuler'ом или Color CC.
  • Плохо подобраны шрифты — тяжёлые шрифты со сложными начертаниями, привет PTSans, приводят к замедлению отрисовки текста в браузерах и приложениях. Откройте тот же фрилансим — более секунды на отрисовку с кучей сторонних ресурсов, перестройкой и перерисовкой слоёв по несколько раз.
  • Нет чётких вертикальных и горизонтальных ритмов — позиционирование элементов «на глаз» и «на пиксель» без каких-либо явных пропорций и их гармонизации.
  • Нет чётко выделенных и упорядоченных информационных контекстов, и контекстов взаимодействия
  • Не контролируется информационный шум

А что с биржами?


Они не работают.

В целом 95% народу работает «за еду» со всеми соответствующими проблемами.

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

Эти проблемы достаточно легко решить — можно прививать навыки контроля качества и организации процессов разработки уже прямо в бирже, так как всё это достаточно шаблонные задачи. Но опять же биржам нужны дилетанты…

А что «за бугром»?


Ситуация получше, но и люди намного здоровее, и в обществе принято анализировать и решать свои личные психологические проблемы. Потребность в компенсации встречается значительно реже, её принято „оставлять дома“ — все делают свою работу, и не тратят время непонятно на что. Правда и в семейном плане работа слишком сильно влияет на благополучие — «отрываются» в первую очередь на семье. Так что вопросы семейных отношений сотрудников очень важны для иностранного руководства, и частенько встречаются офисы со своими психологами, чаще всего это семейная психоаналитика с вкраплениями каких-то фрейдизмов и „попсовой“ гештальтпсихологии. В Германии вообще можно встретить рядового профессора-психоаналитика, который будет анализировать, почему же в офисах разработчики так громко и так много „пускают газы“, у них это вполне приемлемо в рамках этикета, но не в таких количествах (true story)…

Качество продуктов, которые разрабатывают фрилансеры и удалённые сотрудники в Штатах или Европе, часто на несколько порядков выше чем в РФ и СНГ в целом, при сохранении тех же диапазонов цен. Они честно едят свой хлеб, чего уж точно не сказать про местных.

Ситуация с высшим образованием конечно намного лучше, но оно тоже сейчас испытывает кризис. Мне очень нравится подход MIT с Case Studies — аналог нашей лабораторной работы. Учат релятивную алгебру и нормализацию баз данных — пилят сайтик на рельсах с CRUD'ом и полностью покрывают тестами. Case Studies переписываются раз в полгода, чтобы догнать изменяющиеся требования рынка, новые инструменты и подходы. И это просто не входит ни в какое сравнение с Access'ом…

В итоге за бугром студенты получают навыки, в том числе и организационные, которые точно пригодятся в работе. А наши… ну в общем „много, но дурного“, с 300 человек потока получаются 10 программистов, которые сами сидели и разбирались, остальные пошли „потому что стильно-модно-молодёжно“.

Я так понимаю, что в MIT сейчас хотят массово вводить платную производственную практику с частичным дообучением в университете — и рабочее место будет „забито“, и у студента деньги будут на еду и раздачу банковских кредитов, и пропускная способность заведения очень сильно вырастет, что приведёт к уменьшению цен и возможно уменьшению качества обучения. Но это не сидеть 7 часов на парах и размышлять „на кой ляд программистам эта очистка сточных вод и теология вайшнавизма“…

Заключение


Я считаю, что фриланс является необходимой частью профессионального развития любого разработчика, он прививает гибкость мышления и способен воспитывать достаточно большое количество полезных качеств, которые простым офисным сотрудникам не свойственны. Фрилансер может „набить больше шишек“ за месяц, чем простые работники за пару лет своей работы, он всегда на всё смотрит со стороны и его вовлеченность в психологические игры и компенсаторные процессы либо ниже, либо полностью отсутствует. К сожалению, работает это только в случае сохранения цикличности процессов разработки и наличия профессионального развития, типа того что я описал выше. Конечно же, это не истина в первой инстанции — я старался генерализировать и упустил очень много тонких моментов, у вас может быть как-то по-другому.

Ты повторил over 100500 раз о ригидности и приостановке развития, я сам за собой это замечаю — что же мне теперь делать ?
Не быть тем-самым „хорошим парнем“, не нужно стереотипно потакать любым прихотям и поддаваться на манипуляции — это „The USSR way“, который ёмко укоренился в мозгах людей с поведенческим шаблоном „Не жить, а работать“. Подавление потребности личного развития приводит к внутреннему напряжению, которое компенсируется излишней занятостью — это психологическая игра в „святого великомученика“, который работает по ночам. Вы не будете принимать обоснованных решений — у вас задача „вырабатываться“, и не факт что эта занятость будет чем-то конструктивным. Даже если и будет, то тут строят программное обеспечение, а не хрущёвки с требованиями 70х годов, хотя требования к обоим сейчас не особо отличаются.

Хватит, просто хватит, Вы выше всего этого!

У остальных „всё будет хорошо“, они не будут следить за собой, анализировать свои собственные поступки, и соответственно, рано или поздно, их развитие полностью приостановится, и заменится задачей накопления материальных благ. В итоге получается психбольница в руках пациентов.

Руководителям могу посоветовать поощрять любые попытки самоанализа как подчинённых, так и своих собственных. Нужно понимать, что к самоанализу склонны только те люди, которые готовы решать свои проблемы и становиться „лучше чем вчера“. Люди которые не хотят осознавать то, чем сами являются — не способны к личному и профессиональному развитию, принятию конструктивных решений. Они будут делегировать их другим, а себе сгребать все лавры и ещё и поощрять подобное поведение для компенсации ненависти к своей сущности где-то глубоко в подавленном подсознании. Таких слишком много, и я не могу дать „универсальной пилюли“ для того что бы с ними можно было принимать какие-либо решения. Сам в поисках.

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

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

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

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

В комментариях прошу указать какие основные антипаттерны и когнитивные искажения вам чаще всего встречаются.

Спасибо за внимание.

P.S. В комментариях примитивные проекции неприятных суждений на автора этой статьи — просто такая защитная реакция, когда люди про себя самих что-то прочитали. Радует, что кого-то „зацепило“.
Юрий Ярош @voidnugget
карма
6,2
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (82)

  • +6
    Если «минусуете» — пишите причину, чтобы можно было что-то обсуждать.
    А то получается что «правда-матушка глазки режет», возникает внутреннее напряжение которое компенсируется «заминусовыванием».
    Я понимаю что это всё можно спихнуть на мои пунктуационные ошибки, вольный стиль повествования и достаточно плохое знание русского.

    Я потратил достаточно много времени на написание этой статьи — обратную связь можно дать просто из уважения, чтобы я понимал в чём заключаются мои ошибки и не допускал их в будущем.
    • +3
      Спасибо за проделанную работу, поначалу текст показался сумбурным, но стоило поймать ритм и все ок. Местами узнал себя, немного огорчает, но и мотивирует. :)
      • +2
        В следующей статье, или статьях, «RESTful services — you're doing it wrong» буду рассматривать особенности DDD при проектировании RESTful сервисов в рамках SOA с CQRS-ES'ом и реактивностями. Обычно пишут «одна таблица БД — один CRUD контроллер», статья о том как написать один контроллер для любого количества таблиц анализируя схему базы, по ней же автоматом генерировать правила серверной и браузерной валидации форм, выделять AAA сервисы.
      • +1
        Что-то мне уже перехотелось статьи на хабре писать — слишком много «весёлых персонажей».
        • +4
          Добро пожаловать на Хабр. Или ной, или пиши, тут другого не дано.
          • 0
            Согласен, ваш ник соответствует моим намерениям.
  • –1
    Статья толковая, только сильно большая. Почти методичка у вас получилась.

    Боюсь те, кому это могло бы помочь — не смогут оценить (не прочтут). А кто сможет оценить — уже прошел через все это.

    Нужно было писать серию статей.
    • –3
      Понятное дело что тут можно разбить всё на 2 части и разбавить иллюстрациями для наглядности, но я решил просто побыстрее опубликовать и не заморачиваться. Если бы рассчитывал на большую часть «серой массы» — нарисовал бы комикс. Даже если прочтут половину — будет замечательно.
      • +2
        разбавить иллюстрациями для наглядности, но я решил просто побыстрее опубликовать и не заморачиваться

        А, может, все же стоило?
        • 0
          Просто не было возможности этим заниматься.
      • 0
        Не считаю себя большей частью «серой массы» и нормально отношусь к большим текстам, но, действительно, многовато. Разбить и снабдить картинками было бы читаемее. Тем более, что это скорее проявление уважения к читателю, а не адаптация под серую массу.
        • +1
          Согласен, но это статья задержалась на пару недель, и на очереди уже совсем другая… так что я решил оставить так как есть, кому будет интересно — почитают и скажут что об этом всём думают.
  • +6
    После фразы «Основными причинами конфликтов и организационных проблем являются» и нумерованного списка во мне проснулся студент, который начал листать методичку в поисках примера «лабы» и заданий, пропуская «теорию».
    Не обижайтесь.
    • 0
      Не понимаю о какой теории идёт речь?
      Если нужен конкретный список литературы для ознакомления с базовыми понятиями, то лучше так и написать.

      Понятие компенсаторных процессов является общепринятым в психологии, и я не думаю что его нужно подробно объяснять, по этому поводу можно почитать классические труды Альфреда Адлера. Я не хотел разбирать каждый частный случай когнитивного искажения и описывать как он влияет на организацию труда — их очень много и это задачи социальной психологии, а не психологии управления, можно почитать Майерса «Социальная психология», правда там довольно поверхностно. Считаю нецелесообраным использование профессиональной лексики психологов на этом ресурсе — старался излишне не усложнять и давать ссылки для ознакомления. Вот статья психолога для сравнения. Конкретный список литературы сформулировать не могу, так как писал всё с собственного опыта. Можно почитать популярной психологии: Берна «Игры в которые играют люди», и Козлова «Философские сказки для обдумывающих житье...», а вот Юнга читать без предварительной подготовки я не советую.
      • +2
        Дружище, ты ведь достаточно развит чтобы понимать, что обычно бывает за «терапию без запроса». Так чему ты удивляешься? У нас таки действительно сильно болезное общество и то что ты получаешь в качестве фидбека это нормальная(обычная) реакция людей которых потыкали в их самые «любимые мозоли».
        Кстати стремление помочь всем вокруг стать лучше — таки тоже невроз. Их и так неплохо кормят. И дорога у каждого своя.
        • 0
          Я не пытаюсь помочь всем подряд. Хочу чтобы проблемы людей, которые ничего не собираются с ними делать, были более ясны тем, кто пытается что-либо осознавать — «тыкаю в мозоли» специально чтобы всплывало наружу и было очевидным. Я и не отрицаю наличия невротизации — у меня было достаточно тяжёлое детство. Прекрасно понимаю что означает позиция помощника (по Берну), но я не играю роль «благородного рыцаря бегущего на помощь». Эта статья также является инструментом решения моих проблем связанных с прокрастинацией, пытаюсь перестраивать свои поведенческие шаблоны. Пока что по моим субъективным — выходит достаточно неплохо.

          Сейчас после совка, почти никто не знает чем занимаются психологи. Отчасти я хотел показать что есть проблемы, и их нужно решать — некоторые самостоятельно, а некоторые с помощью сторонних специалистов, которых ещё и нужно поискать. У меня было не так много удачных примеров терапии, а вообще обычно даже дальше консультаций дело не доходит — часто смотришь на психолога и думаешь: где там психология, а где эзотерика. Да и методы сейчас довольно «попсовые» — сплошные гештальты, возрастная психология и расстановки, позиционируются прям как «пилюля от всех болезней». Приходится довольствоваться тем что есть.
  • +1
    Все дело в сиюминутной выгоде. Заказчику в текущий момент выгодно сделать быстро и дешево. Заказчик готов платить за поддержку и доработки, когда расходы размазаны по времени. Заказчику проще в течение года заплатить сумму большую, чем сумму в полтора — два раза меньшую, но за 2 месяца. В итоге платит дешево за плохую реализацию, но теряет на поддержке и эксплуатации в течение эксплуатации.
    • +1
      Хорошая организация работы сокращает сроки реализации проектов, упрощает поддержку и масштабирование.
      • +1
        Я не спорю, я про психологию заказчика. Ситуация как с кредитами. Для многих проще заплатить больше, но в течение длительного времени, чем меньше, но сразу. Во фрилансе это приводит к перехвату заказа дилетантом, потому как профессионал адекватнее оценивает стоимость разработки.
        По себе же знаю. Заказов не много, делаю дорого, но заказчики всегда возвращаются. Хвалят за поддержку и качество.
        • +2
          Это частный случай когнитивного искажения.
          Я не видел случаев когда люди экономили на внедрении хорошего тестирования и аудита, и после этого тратили меньше в долгосрочной перспективе. Как пример могу привести RTB-биржу Datamind (Тинькова) на которую потратили три миллиона рублей и 3 года разработки, вместо года и одного миллиона — на аудите, организации и исследованиях «сэкономили». В итоге продали неизвестно кому потому что не смогли допилить самостоятельно…

          С задачами выработки требований и контроля качества должен быть знаком непосредственно сам заказчик, иначе он получает «кота в мешке». Я под поддержкой подразумеваю долгосрочную поддержку — мониторинг нагрузки, различных угроз и администрирование в течении 10 лет, с сохранением работоспособности при обновлениях зависимостей, и возможность отката в случае проблем с обратной совместимостью. У вас же под поддержкой подразумевается доработки в процессе выработки требований — это непосредственная часть реализации проекта.

          Можно по минимуму: внедрить менеджмент зависимостей, написать приёмочных тестов, и не нужно будет вечно переключаться в браузер да клацать F5 — уже значительная экономия времени, особенно со всякими LiveReload'ами фронтенда. После релиза можно провести нагрузочное тестирование каким-то jMeter'ом, да отпрофилировать под нагрузкой, чтобы понимать где есть узкие места. И этого уже вполне достаточно, но большинству фрилансеров не свойственно.
  • +1
    Хорошая статья, читал с удовольствием.

    Даже был вынужден обновить свои знания, кто такие «ригидные» разработчики (уж больно часто мелькает по тексту).

    Вопросы автору — а какой средний срок выполнения заказа? Какой максимальный срок выполнения заказа? Какой максимальный срок сотрудничества с одним и тем-же заказчиком?
    • 0
      Ригидность — это неспособность менять свою точку зрения на вещи при получении новой информации, особенно когда она противоречит старым взглядам. Если рассмотреть хотя бы сотню различных когнитивных искажений, то на это уйдёт не один десяток статей, так что я описал только самое частое с чем приходится сталкиваться.

      Срок выполнения заказа зависит от вовлечённости заказчиков / руководства в процесс выработки требований

      Я лично на рынке СНГ и Европы выделяю 4 типа заказчиков
      • Люди некомпетентные, которым в первую очередь нужен результат — не участвуют в выработке требований, не могут взять на себя ответственность и сформулировать задачу которую нужно решить, грешат «радужными пони» потому что «хотелка и кошелёк» позволяет
      • Люди некомпетентные, у которых было достаточно много плохого опыта работы с фрилансерами и студиями — требуют хотя бы частичного подтверждения квалификации, но оценить её как-либо не в состоянии поэтому создают «ореолы» для компенсации. Участвуют в выработке требований достаточно активно, но могут грешить «вот я заказчик — я знаю как лучше».
      • Люди с средними и зачаточными навыками разработки, без навыков организации её процессов — из-за своей ригидности отвергают любые незнакомые подходы и инструменты. Тесты и аудит для них пустая трата времени, а в выработке требований не участвуют ввиду потребности в компенсации внутреннего напряжения: «как же так? я уже не такой умный ?».
      • Люди с хорошими навыками разработки, понимающие важность контроля качества, но никогда не осуществлявшие её. Они не ригидны и способны быстро учится любым премудростям. Чаще всего у них не возникает компенсаторных процессов, но с ними приходится долго возится в виду повышенных накладных расходов на коммуникацию из-за преодоления определённого порога вхождения.


      Если второй тип некомпетентного заказчика с плохим опытом сотрудничества способен учится на своих ошибках и вникать в принципы организации процессов разработки — с ним можно сотрудничать достаточно долго и продуктивно. После реализации первого проекта такие люди просто «боготворят» и радуются, но и свернуть куда-то «на сторону» у них смелости не хватает, в итоге это вечные «прикрути то… прикрути сё...». С ними можно сотрудничать до тех пор пока они не захотят построить что-то очень большое в составе целой команды разработчиков, есть большая вероятность что её будет формировать фрилансер, но это довольно стихийные процессы требующие большего опыта, чаще всего они заканчиваются провалом, так как без опыта анализа организационных проблем пытаться чем-то руководить — «гиблое дело». Сотрудничество может затягиваться до 2-5 лет, а бюджеты проектов в среднем 3000-8000$ без поддержки и в зависимости от сложности. Сроки реализации порядка одного-трёх месяцев, но опять же зависит от качества выработки требований. Можно спокойно рассчитывать на долгосрочную поддержку со стабильным пассивным доходом.

      В остальных случаях сотрудничать не получится — не выработаются требования к продукту и не будет ясно что нужно в итоге.

      Вот в случае со сторонними разработчиками которые хотят развиваться и развивать продукты над которыми работают, ситуация немного сложнее: работают совместно, активно участвуют в выработке требований, но вот после завершения реализации чего-либо рассчитывать на долгосрочное сотрудничество не приходится — сами разбираются своими силами. Тут бюджеты и задачи обычно поменьше и попроще — в среднем 2000-3000$, а проекты обычно затягиваются на полтора месяца

      Дальше CRUD'а дело не идёт, и наукоёмкие задачи встречаются крайне редко.
      Последнее с чем мне приходилось работать — разработка средства распознавания reCaptcha на основе DeepLearning методов, получилась эффективность в 92% что более чем приемлемо. Недавно поставили задачу эмулировать поведение пользователей на сайте теми же методами, для того что бы обходить noCaptcha, правда пока не ясно как это осуществлять — в теории это должны быть генераторы на основе RBM с автоэнкодерами.
      Подобного рода проекты — просто праздник…

      В среднем ставка на рынке СНГ от 12 до 20$ в час не зависимо от компетентности.
      В Штатах получается от 15$ и до 40$ в час, но возможно двойное налогообложение в некоторых случаях.
  • +2
    Спасибо, статья хорошая, узнаю много моментов из офисной жизни, из которой как раз пытаюсь уйти (а ведь чуть не засосало в болото ничегонеделания за нормальные деньги). Если биржи — плохой вариант, то что тогда хороший?
    • +1
      Биржи не очень плохой вариант, просто там слишком высокий процент «весёлых» людей, для фильтрации которых нужен опыт, в том числе и негативный. Бывает что люди с кошельками мигрируют с биржи на биржу в надежде найти «супермэнов», но этот момент ещё нужно уловить, да и не факт что с ними можно работать. Если человек строит дома, то и к построению ПО будет относится так же… и будет потом угрожать приковать к батарее в случае задержки сроков — уже было так :3 Не то что бы это помогло ему вписаться в сроки и в бюджет, но хорошо что хоть никто не пострадал.

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

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

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

      Такое было в Штатах в 80х перед рассцветом различных моделей управления и менеджмента разработки ПО, со всеми этими странными сокращениями типа ITIL и т.п. и «менеджерскими таблетками» от всех признаков раздувания бюджета. Правда у нас всё на рынке так и застряло…
  • 0
    Фрилансеры за рубежом работают на порядок лучше? При этом фрилансеры в России работают и за рубежом. А уровень качества русского фриланса на биржах оценивается довольно высоко.
    • 0
      Вы не представляете как весело, когда московская студия ставит ценник в миллион рублей на iPhone приложение, в итоге нанимает фрилансера и платит ему 300 тысяч… они просто затягивают все сроки в 3 раза (4 месяца). Итальянцы управились за 90 тысяч и 3 недели, при этом их дизайн был просто замечательным и не в какое сравнение не входил с русским. Когда есть такие примеры, то как-то о качестве думать не приходится. Даже если и приходится, то основные проблемы которые я описал в статье у русских решать не принято — «лишь бы работало» и не более.
  • +4
    Вашу статью сложно читать — она написана «рваным» языком. Такое изложение неплохо для конспекта лекций,
    но мы здесь не нерадивые студенты, а Вы — не преподаватель.

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

  • –2
    OnoIt Я не хотел разбавлять и дал минимальные поверхностные примеры чтобы не раздувать до цикла статей, которые потом будет сложно воспринимать в целом. У всех разное восприятие — если у вас мозг не приспособлен к быстрому составлению мнемонических (ассоциативных) матриц, я с этим ничего не могу поделать. Достаточно много человек восприняло стиль этой статьи нормально.

    Хорошая проекция.
    В чём выражается моё неуважение?
    • +3
      В данном случае — в фразе «если у вас мозг не приспособлен ...» и т.д. И у всей статьи такой тон: Дартаньян рассказывает.
      • +1
        Я не хочу описывать причину по которой эти слова воспринимаются как выражение подобия личного превосходства, к сожалению это не так.
        Скажу лишь что я отношусь к этому как к индивидуальной особенности — я бы не написал статью «для всех», даже если бы постарался.
        Всё люди воспринимают информацию по разному. Тут очень много провокационного материала написанного с целью помочь взглянуть на ситуацию и перспективу «со стороны» — естественно у некоторых могут сформироваться агрессивные защитные реакции, и это нормально.
  • –1
    Обратил внимание на стиль изложения — многие вещи изображены в слишком негативных тонах.
    Дочитал статью и как громом поразило — ЮРИЙ!

    Да, да, тот самый Юрий.

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

    Дорогой Юрий, что ж ты не доделал и отказался от денег, когда они были тебе так нужны? Что ж ты постоянно говорил о долгах, просил денег и так и не выпустил бету?

    P.S. Прошу прощения у хабрасообщества за вынос сора из избы, но увидев сей печатный труд — удержаться просто не смог.
    • 0
      Я не знаю тот ли самый я Юрий, или нет — у меня было пару недоброжелателей которые пользовались моими паспортными данными.
      Но и случаи «затягивания» сроков тоже случались довольно часто — все причины описаны в статье. Чаще всего, это чистой воды мои личные мотивационные проблемы. Если вы хотите что-то обсудить — лучше писать в скайп или в личку.
      • 0
        После того как вы, уважаемый Юрий, 3 месяца обещали выкатить «завтра» и после этого перестали отвечать в скайпе совершенно — пожалуй, в личку или скайп писать вам я не буду. Насчет личности у меня сомнений нет никаких.

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

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

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

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

          По этому я просто не могу сотрудничать с 80%ами заказчиков с существующих русских бирж.
          Мне проще сотрудничать с серьёзными конторами которые выпускают достаточно простые продукты с проработанными требованиями.
          • +1
            Никто не знает вашей конкретной проблема с этим заказчиком. Однако, просто пропадать же нельзя. Нобходимо все объяснить. Если договориться не получается и перспектив не видать, то хотя бы расставить точки над i. Вернуть деньги или часть, извиниться за потраченное время. Вашей ошибкой в данном случае является то, что вы не распознали человека с которым решили работать и за это надо брать ответсвенность. А объяснять все проблемы психологическим нездоровием людей… как-то высокомерно. Вы то совершенно здоровы? Кто диагноз ставил?
            • 0
              Я не трачу время на обучение людей которым не нужен опыт организации работы, а нужны готовые продукты любого качества.
              У вас довольно поверхностные представления о психологическом здоровье. Спросите любого психолога о здоровье социума в целом — будете сильно удивлены. Почитайте что-то с поп-психологии.

              Психология не психиатрия — для достижения расстройств и пограничных состояний нужен ещё целый ком проблем и соответствующее окружение. У меня его нет, поэтому я могу спокойно смотреть на вещи со стороны и не сильно вовлекаться в эти психологические игры.
              • +5
                Вам нравится давать оценки людям. Причем субъективные оценки выдавать за объективные на основании «знаний психологии». Вы практикующий психолог? Думаю нет. Но вы можете смотреть на вещи со стороны :)

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

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

                    а так хотелось…

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

                    Кстати, тоже дам вам рекомендацию кое-что почитать
                    • 0
                      Пока что я увидел, что я
                      • безответсвенный
                      • необъективный
                      • высокомерный
                      • плохо знаю психологию и психологические процессы
                      … может я что-то забыл?

                      Это просто суждения о моей личности, где критика статьи?
                      Да, конечно, — я плохой. Со мной не нужно дружить… что-то ещё?

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

                      У меня не возникает отрицания, но возможно возникает рационализация некоторых суждений.

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

                      Что мне там нужно было почитать?..
                      • +5
                        Если вы признаёте своё дилетантство в психологии, не парьте людей этой темой — это не ваше. Очень некрасиво выглядит.

                        Мне понравилась статья, но после ваших комментариев у меня возник когнитивный диссонанс. Такое впечатление, что автор статьи и автор комментариев — два разных человека. Вообще, как-то так случайно получилось, что, после вашей лично просьбы в конце статьи не заниматься обсуждениями ради обсуждений, 24 комментария из сорока шести — ваши — это половина всех комментариев. Вы просто не даёте людям выразить свою точку зрения, и на любое слово встаёте в защитную позу, закрываясь простынями текста. Дайте уже людям спокойно без вашего участия своё мнение высказать.
                        • –3
                          Согласен, я просто ведусь на примитивные провокации и проекции — никогда не думал что тут всё так печально.
                          Ну пока обсуждают только мою личность, и никакой критики статье я не получил.
                          Отвечаю когда спрашивают, уточняю где меня неправильно поняли.
                      • +1
                        Относительно статьи — критику дали другие люди, которую вы не воспринял так, как то следовало сделать. Моя критика касалась вашего поступка и его оценки. Поступки важнее слов. Ошибки все совершают, но минимальные нормы деловой этики соблюдать необходимо. Вы согласны?

                        По поводу всей этой психологической чуши — это просто смешно читать. В предлагаемой вами манере конструктивной дискуссии не получится.
                        • 0
                          Критика касалась того что у кого-то «аукнулось», а я должен был быть «мягче», и того что тут людям нужно картинки глядеть, а не структурированный текст читать… «нежные» все такие. Всё остальное — ваше личное мнение, которое я не разделяю, можете при нём и остаться.

                          p.s. читать не смешно, а влом… так что точно не получится.
                          • 0
                            Юрий, я обозначу вам проблему, связанную с вашей статьей.

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

                            Знание поп-психологии позволяет мне, как менеджеру проектов, нейтрализовывать 90% негативных выпадов людей и объяснять почему стоит делать так и никак иначе. Да, я трачу время на то, чтобы объяснить что-то, иногда — 2 или 3 раза. На практике самый неадекватный заказчик понимает с 5 раза.

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

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

                            Иначе — вам не место во фрилансе, поскольку тут каждый сам себе — менеджер по продажам, психолог, исполнитель и так далее.

                            Надеюсь, моя позиция ясна и прозрачна.
                            • 0
                              Ну да, точно… нужно просто выпускать продукты что бы все были довольны их наличием, и получали прибыль.
                              Мне это просто не интересно — я не хочу быть «экспертом».
                              • +2
                                Юрий, выпускайте продукты, которые вам нравятся больше всего. Речь не об этом.

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

                                Более ни о чем не прошу.
                                • –3
                                  Сам такой.
  • +1
    Действительно не было положительного опыта работы с биржами? Меня в частности интересует Odesk. Я слышал хорошие отзывы. В том плане, что там можно выйти на адекватных заказчиков. С отечественными биржами согласен что все плохо — это знаю по собственному опыту. Но с зарубежными не работал. И где вы находите/находили проекты или они сами вас находят? LinkedIn, сарафанное радио, что-то еще?
  • 0
    Я тоже думал про oDesk — там водятся более-менее адекватные люди, но и дилетантов везде хватает.
    Мне очень не нравятся принципы предоставления гарантий выполнения проектов и их оплаты. Существующие системы тестирования и отчётности ничего толком не гарантируют — эти вещи можно было бы сделать гораздо открытие и прозрачнее, но они ограничены «политикой партии».

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

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

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

    Также цель этой статьи — вызвать резонанс и внутреннее напряжение, посмотреть как весело люди начнут их компенсировать.
  • +2
    Мне довольно-таки часто встречаются две ситуации:

    1. Заказчик думает, что long-term — это пряник. И использует это в качестве украшения проекта. Например, нашлась какая-то для меня интересная задачка, которая, как мне кажется, даст мне какое-то развитие. На этапе обсуждения вставляется фраза: «если с этим проектом всё нормально получится, у меня будет ещё куча подобных заданий (в отдельных случаях — просто ещё куча другой работы)». И это звучит совсем не в виде вопроса: «а у тебя вообще есть планы строить долгосрочные отношения?» Интересно, что заказчик даже не задумывается над тем, что долгосрочные отношения должны быть привлекательны для обеих сторон, считает, что long-term — это прошитый в железе заводской пароль такой у фрилансеров, который подходит к каждому. Мне очень часто не хочется продолжать работу после того, как я полностью сделал всё, что было описано в проекте. Возникает такая неоднозначная ситуация: если я прямо скажу человеку, что я нанимался только на этот проект и мне неинтересно продолжать, я могу схлопотать от него более низкую оценку, что напрямую влияет на мой рейтинг на бирже. Если я продолжу с ним работать, он меня завалит неинтересной работой, которая мне в итоге надоест, и я закрою контракт, что в итоге обидит клиента, и он мне влепит оценку ещё ниже, что ещё хуже скажется на моей репутации. В итоге, выход из проекта очень сильно затягивается — приходится искать какие-то отмазки уважительные причины, вроде надвигающегося цунами, которое сломает мне Интернет и не позволит продолжать работать дальше.

    2. Заказчик думает, что можно обсудить все детали, оговорить размеры оплаты, а потом пропасть на 1–2 месяца — не начиная контракт. После этого можно появиться — будто никакой паузы не было — и сказать: «ну что, давай начинать» — совершенно не интересуясь тем, а есть ли у меня сейчас желание и свободное время всем этим заниматься. Он, как бы, оставил меня 2 месяца назад в состоянии «всё обсудили» и думает, что я после его появления могу, как бы, сняться с паузы и сразу начать работать.

    Мне кажется, что в этих ситуациях заказчики просто неправильно понимают смысл фриланса, почему-то считая его подобием обычной стационарной работы, где long-term и гарантированные объёмы работы играют большую роль. (И где бюрократические моменты могут привести к тому, что обсуждение особенностей какого-то проекта и конкретно начало проекта могут быть разделены длительными сроками, в течение которых человек работает на том же самом месте и постоянно чем-то ещё загружен.)

    Причём, обе эти ситуации практически не коррелируют с национальностью заказчика — я не могу как-то выделить, что, например, русские заказчики чаще так делают, а заказчики из Нидерландов — реже. В основном, частота одинаковая.

    Остальное вы, в принципе, упоминали — вроде некомпетентности. Часто встречаются ситуации, когда в описании проекта упоминается: «дел на пять минут для того, кто в теме» или «мне мой знакомый программист сказал, что это плёвая работа». От таких заказчиков хочется бежать — как от огня.
    • 0
      Согласен, но…

      1. long-term поддержку можно реализовать только при покрытии приёмочными тестами хотя бы 60% функционала, и наличии хотя бы базовой документацией с описанием модели БД, её агрегации, ведении статистики и отчётов, и основными описаниями процессов. Нужно повышать BusFactor — что бы не было «незаменимых». Иначе получается что и на проект некого пригласить, и заниматься особо не охота… а если кто и придёт так сразу «наделает делов». Без всего этого долгосрочная поддержка — это звонки в 3 часа ночи с криком «оно отвалилось после обновления, давай что-то думать». Меня подобное отношение ужа на порядок достало, и мне просто проще поставить перед фактом — я не хочу быть незаменимым, и вам придётся ради этого расширить бюджет на 20%. Я не такой тактичный в сотрудничестве, и для меня не важно что обо мне пишут другие люди — возможность признать свои ошибки и показать другим что ты способен на них учится, наоборот, часто сближает с нормальными людьми, а те кто судят по циферкам на экране — сами по себе не способны вывести какие-либо критерии компетентности и используют подобного рода суррогаты для компенсаций. Естественно организовать хорошие процессы они не в состоянии, и не в состоянии этому научится — таких большинство.

      Внедряйте приёмочное тестирование продуктов которое разрабатывайте — если кто придёт, так ничего не поломает, а мозги будут парить только первые 2-3 месяца. Но можно спокойно идти работать куда душа пожелает…

      2. Это люди которые банально не могут принять ответственность для того чтобы правильно сформулировать задачи — замещают это описанием абстрактных реализации, вместо того что бы описать конкретные сценарии использования и спланировать возможные намерения пользователей. Это типичный антипаттерн «I told you so», с компенсацией «я хочу быть самым главным, даже если я неправ». Естественно, если любые «хотелки» подобного рода потом приведут к странным последствиям — вина падёт на исполнителя. С таким контингентом просто невозможна выработка требований.

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

      Рыночные требования для РФ и СНГ на одном и том же уровне, так как все привыкли работать с методами 70х-годов, которые лишь годятся для построения «хрущёвок». Ну и фрилансеры предоставляют как раз такое же качество…
      • 0
        Вы неправильно поняли то, что я вкладывал в выражение long-term. То что я вкладывал: в проекте написано, что «нужно написать функционал, который позволит на фото товара накладывать пользовательские картинки — с возможностью масштабирования/поворота/обрезки и т.п. + несколько дополнительных фишек, связанных с этими „фото на чехлах”». После того, как это сделано, заказчик начинает заваливать другой работой: установи друпал, поправь на другом моём сервере с джумлой CCS для IE6 — весь этот long-term не связан с началом проекта вообще никак. Просто ему понравилось, как я сделал проект, и он думает, что я априори согласен с ним работать и дальше — не важно, что за характер имеет дополнительная работа.

        Я только такую долгосрочную работу имел ввиду. Мне часто такие ситуации попадаются.
        • +2
          Более 10 лет во фрилансе/удалёнке, универсальный ответ — уже подписался на другой проект, свободного времени не осталось, возможно месяца через два.
          • 0
            Обычно так и делаю.
        • 0
          Это простые вещи на «раз сделал и забыл», я говорю о полноценных порталах со сложной инфраструктурой, богатым фронтендом и API для моб. приложений… С СMSками обычно принято школьникам и студентам играться. Отказаться от реализации тех или иных фич не составит особого труда, так как обычно это достаточно «кривые» решения кто бы их не писал. Другое дело что потом «чёрт ногу сломит», но это уже проблемы заказчика — нужно было давать требования к документации, а не «работает вот и хорошо»…

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


            Ну, тогда сотрите мой комментарий. Просто с самого начала я ориентировался на эти ваши слова:

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

            В комментариях прошу указать какие основные антипаттерны и когнитивные искажения вам чаще всего встречаются.


            Я наверное пропустил момент, когда вы начали говорить о порталах. Совсем забыл: я подписался на другой пост и, увы, у меня в ближайшие 2 месяца не будет свободного времени на обсуждение порталов, сложной архитектуры и богатого фронт-энда.
            • 0
              Нет проблем, пускай висит — тоже общественное достояние в котором есть доля правды.
  • +1
    Спасибо, очень интересная статья.
    • 0
      Рад что понравилась :)
  • +2
    В целом довольно интересная статья. Вот только после прочтения комментариев двоякое впечатление. С одной стороны в статье описаны проблемы коммуникации, с другой стороны, судя по комментариям, у самого автора есть большие проблемы с оной.
    • –2
      Например?
  • +1
    Похоже, на любой не похвальный комментарий автор рвется ставить диагнозы. Надеюсь, показалось.

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

    Вроде бы «юзабилити» — это такое свойство элемента управления. Т.е. «удобность» кнопки, грубо говоря. Задач у юзабилити в принципе никаких быть не может. Ну, свойство потому что. Это как «задача сладости пироженки». UX («опыт пользователя» по-русски) — это, процесс, который происходит между человеком и интерфейсом, когда первый делает что ему надо, а второй минимально ему в этом мешает. Грубо говоря, опять же. Задач у UX тоже никаких нет. Путь, который проходит пользователь (от экрана логина до первого входящего сообщения, например) — уже результат решения задач.

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

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

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

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

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

      Я не рвусь ставить диагнозы, есть теория и практика, а психологи почти во всём согласны… тем более это слишком примитивные процессы. Не хочу раскладывать по полочкам суждения vilgelm-hero и его проблемы — он потом меня просто возненавидят (об этом тоже написано в статье, если внимательно читать), но могу скинуть в личку. Я пальцем не тыкаю, просто он сам к себе применяет генерализированные общие суждения которые к нему непосредственно не относятся (пишу «люди», а не «ты»). Наверное, не просто так же это происходит. Здоровый человек промолчал после ответа на свой же вопрос, а не стал бы столь явно указывать свои проблемы под действием сильного эмоционального напряжения.

      Конечно жаль, что товарищ brizzz не смог написать ничего сложнее чем:
      «Ты кинул заказчика — ты плохой и статья твоя дерьмо.»,
      это на столько же весело как и написать:
      «Как вы не едите мяса ?! Гитлер был вегетарианцем! — Жрите мяяясо!»
      Я не виню его, он застрял в PHP со средними навыками симфонии между «мясоперерабатывающим цехом» и «обучением».
      Играет в «доброго и пушистого» «заказчик всегда прав», и это его личный выбор: «не жить, а работать».

      То что я стараюсь отвечать на каждый комментарий — подразумевает то, что я ценю позицию комментирующих, и хочу выразить свою, чтобы мы могли её обсудить. Это проявление уважения к моим читателям.
      • 0
        Уважаемый Юрий.

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

        И ставит диагнозы по нику — prntscr.com/5lsx1g
        Так что товарищ reznik_e получается прав.

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

          Где именно я пишу о неприемлимости «диагнозов по фото»?
          По вашим комментариям можно судить о многом… и там психологу, к сожалению, делать точно нечего.
      • +2
        Вас понял. Про юзабилити и художников везде согласен, это у меня скорее по формулировке замечания были. Насчет диагнозов больше не комменирую, а то мы до праздников вне вылезем :-)
      • +1
        Видимо, в своих комментариях я вас за живое задел, 3 дня не дают покоя. Только вы не конуструктивные выводы из них сделали. Вы искажаете и утрируете смысл моих слов. Вы сами реагируете и не ведете себя как «зрелая личность». Я не говорил, что статья дерьмо. Просто ценность её упала в моих глазах после общения с вами. И я высказал свое отношение к вашему поступку. Относительно прочей полемики, в том числе ваше очередное оценочное суждение в мой адрес — это только в очередной раз подтверждает мое мнение о вас. Обратите внимание на то, что не я один высказался относительно вашей манеры общения.
        «Если ото всех вокруг воняет дерьмом, может это ты сам обосрался?» © mr. Freeman
        • –1
          Не, на самом деле мне смешно это всё читать… я три дня угораю xD
          Я ничего не говорил о вашей зрелости, и не думаю что проекция «ты сам такой» здесь уместна, вы сами в подсознании приняли это суждение к себе самому, на то есть причины, которые я не буду здесь обсуждать, за ненадобностью. Я не говорю что все вокруг дерьмо, я говорю что дерьма много, и оно есть у всех, и с ним нужно что-то делать. Не нужно так явно разбрасываться им в комментариях и считать это «почётным долгом». Просто полный ad hominem.
  • 0
    P.S. Как плохо, что люди не понимают разницы между психическим диагнозом и психологической проблемой.
  • 0
    Пишите больше, автор, у вас хорошо получается. Хотя, наверное, стоило бы разбить статью на несколько, много разных тем затронули.
    • 0
      Рад что понравилось :)
  • +2
    Спасибо автору за статью. Мне как психологу было полезно узнать субъективное мнение программиста об организации труда. Делиться опытом всегда полезно, осуждать за личное видение ситуации — глупо. У читателей могла бы быть совсем другая история и манера изложения. Приятно, что люди из других сфер владеют базовыми понятиями науки о человеке, пробуют по-новому посмотреть на свои рабочие конфликтные ситуации. Насчет «терапии без запроса» и «диагнозов» — громко сказано. Максимум — субъективная «консультация» автора по ряду вопросов и собственное мнение.

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

    Также интересно было понаблюдать за реакцией людей на данную субъективную статью автора. В реальном взаимодействии люди неосознанно выпячивают свои проблемы, пытаясь критиковать или давать советы. vilgelm-hero, после какой-то неудачи с проектом Вы подсознательно негативно реагируете на людей с именем Юрий. Получается, неосознанно формируется «мир с тем самым Юрием, который кинул». А значит — травма. Как не крути, но именно Вам стоит разобраться со своими проблемами, в частности — с этой непрожитой ситуацией. Советы по поводу этого комментария («как стоило поступить») давать не стоит — все остальные не знакомы с ситуацией непосредственно, «с фактами», а делать выводы не зная проблем 2х сторон — поспешно. brizzz, о какой такой объективности в статье или комментариях шла речь? Тут все делятся мнениями и взглядами на вещи, не более. Переход в разговоре на личности — компенсаторное стремление снизить внутреннее напряжение, поэтому высказывать личное мнение о статье некоторым сложно.

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

    … для того, чтобы избежать проблем, обозначенных в статье не нужно принимать себя таким, какой ты есть.
    [Удивляюсь такой формулировке мысли и перечитываю много раз]
    Уважаемый, с чего Вы взяли, что проблем нужно избегать? Автор статьи делал акцент на человеческом развитии и упоминал как оно влияет на взаимодействие заказчика и исполнителя, для него это важно. Если Вы готовы работать с каждым заказчиком — это только Ваш личный выбор. Обсуждать тут нечего. Далее, упоминание «не нужно быть таким, каким ты есть» противоречиво… Не вводите людей в заблуждение. Получается, Вы видите человека как статическую систему, в которую запихнули всякого разного в 1й половине жизни, а потом она действует шаблонно, ничего не меняя в дальнейшем. Могу Вас разочаровать — человек и его психические процессы динамичны и подразумевают развитие. Если кто-то предлагает по-другому взглянуть на ситуацию — это не значит, что он разрушает Вас как личность.

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

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

    Всем добра!
    • 0
      Спасибо.
  • 0
    Thanks. Это одна из самых длинных статей на хабре которую я прочитал. И пожалуй еще и самая интересная про IT management, отражающая реальность как есть.
    • 0
      Рад что понравилось.
  • 0
    Решил прочитать пока с температурой дома.

    Много всего намешано. В середине часть пропустил. Такое лучше разделаться на 2-3 отдельных поста.

    Хотелось меньше заумных слов и непонятного сленга и больше примеров правильных действий. Кто-то ведь только начинает свой путь.
  • 0
    На счет семи красных перпенликулярных (видео в первой пятой части статьи) есть решение в Интернете:
    https://www.youtube.com/watch?v=UgM1FJDxi2o

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

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

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

      Сейчас занимаюсь разработкой высоконагруженных решений, да и чаще участвую в fulltime удалёнке нежели в one-shot проектах.

      Уже сформировалось понимание blame culture, и навыки решения основных проблем в коллективах.
      Получается довольно неплохо мотивировать сотрудников, да и опытом делиться.

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