Доброго времени суток уважаемые хаброжители, меня зовут Юра, и сегодня я поведаю вам о проблемах высокотехнологичного отпрыска удалённой работы — фриланса, а именно о разработке мобильных, десктопных и вэб-приложений, вёрстке и дизайне. Работаю я в этой сфере достаточно недавно, буквально с 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» из этого списка и перейти к его концу, если влом читать.

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

На уровне третьего курса Компьютерной Инженерии (КИ), Компьютерных Наук (КН) и Программной Инженерии (ПИ) или даже Автоматизированных систем управления (АСУ) и Телекоммуникационных систем (ТС), к сожалению, большинство преподавателей не объясняют в чём же разница между родственными кафедрами, даже если больше половины основных предметов совпадает. В случае с «некомпьютерными кафедрами», которые делают упор на проприетарные решения, 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 года, хотя язык достаточно простой.

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

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

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

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

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

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

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

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

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

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

Из инструментариев сейчас очень популярны:

• 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-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’ках и «Битриксах» достаточно долго, и это хороший опыт.
Хуже всего если они там подолгу задержаться. Смена перспективы очень сильно способствует личностному и профессиональному развитию, но и менять работу слишком часто очень плохо — нужно хотя бы что-то доводить до конца. Петлять нужно, когда возникает «проблема» в английском значении этого слова — это что-то непреодолимое, конфликт, который нельзя разрешить, а всё остальное препятствия на пути реализации продукта.

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

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

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

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

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

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

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

Руководителем проектов в наше время чаще всего становятся по двум причинам

• Предрассудки владельца/заказчика касательно компетентности
• Родственные связи, хорошие отношения или купленное кресло

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

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

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

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

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

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

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

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

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

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

Понятное дело, что разработчики возвращаются к изучению новых подходов и технологий на различных этапах своего профессионального развития. В случае со стартапами, повышение квалификации — очень сложная задача ввиду сложных комплексных требований к проектам и очень сжатых сроков, но и ригидность тоже даёт о себе знать. Для 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 часов на парах и размышлять „на кой ляд программистам эта очистка сточных вод и теология вайшнавизма“…

Заключение

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

Я не писал про

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

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

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

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

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

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

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

Автор:

Источник