{
    "version": "https:\/\/jsonfeed.org\/version\/1",
    "title": "Блог Корейши Виктора, posts tagged: управление",
    "home_page_url": "https:\/\/koreysha.ru\/?go=tags\/upravlenie\/",
    "feed_url": "https:\/\/koreysha.ru\/?go=tags%2Fupravlenie%2Fjson%2F",
    "icon": "https:\/\/koreysha.ru\/user\/userpic@2x.jpg",
    "author": {
        "name": "Корейша Виктор",
        "url": "https:\/\/koreysha.ru\/",
        "avatar": "https:\/\/koreysha.ru\/user\/userpic@2x.jpg"
    },
    "items": [
        {
            "id": "38",
            "url": "https:\/\/koreysha.ru\/?go=all\/timlidy-i-drakony\/",
            "title": "Тимлиды и Драконы",
            "content_html": "<p>Я уже писал ранее, что не просто люблю настольные ролевые игры, а еще и использую их в качестве инструмента для решения командных проблем. С момента написания того поста, я провел пару десятков таких игр. Понял, что оригинальные правила Dnd не совсем подходят для моих целей. А еще научился выстраивать сюжет так, чтобы решать конкретные задачи. Работал над своими ошибками и анализировал результаты.<\/p>\n<p>И в итоге, сформулировал свою методологию, которой готов делится. И презентовал я все это не где-нибудь а на TeamLeadConf2023. Кроме теории в докладе много практики — рассказываю про конкретные кейсы, настоящие командные проблемы, которые мне удалось решить за это время. С удовольствием делюсь записью выступления с вами &#129321; Интересно будет и тимлидам, и HR-ам и любителям ролёвок.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/Viw8feyV4JY\" frameborder=\"0\" allowfullscreen><\/iframe><\/div>\n<p>Это было первый мой выход на такую большую сцену в роли докладчика. Конечно, страшно волновался, торопился. Больше спасибо за поддержку организатору Ксюше Губаненковой и за прогоны Леше Обровцу. Надеюсь, от просмора вы получите и пользу и удовольствие. А если кто-то из вас захочет применить мою методику на практике — с удовольствием готов помочь с этим и вместе добиться результата.<\/p>\n",
            "date_published": "2023-04-12T10:24:49+05:00",
            "date_modified": "2023-04-12T10:24:47+05:00",
            "image": "https:\/\/koreysha.ru\/pictures\/remote\/youtube-Viw8feyV4JY-cover.jpg",
            "_date_published_rfc2822": "Wed, 12 Apr 2023 10:24:49 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "38",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/koreysha.ru\/pictures\/remote\/youtube-Viw8feyV4JY-cover.jpg"
                ]
            }
        },
        {
            "id": "37",
            "url": "https:\/\/koreysha.ru\/?go=all\/timbilding-v-formate-dnd-udel-frikov-ili-panaceya\/",
            "title": "Тимбилдинг в формате DnD: удел фриков или панацея?",
            "content_html": "<p>Сегодня хочу представить на ваш суд экспериментальный пост, в котором попробую предложить лекарство от деградации командного взаимодействия в условиях пандемийной удаленки.<\/p>\n<p>Все мы пережили несколько волн проблем, вызванных вынужденной общей удаленкой. Первой волной были инфраструктурные проблемы — плохо работали камеры и микрофоны, не получалось организовать совместную работу, приходилось переходить на более строгие правила воркфлоу. Второй волной многие испытали сложности с командой — всплывали и обострялись старые конфликты, народ начал массово менять работу из-за изменения условий и глобализации рынка, у многих в компании были утеряны или деградировали целые блоки знаний и процессы. Со всем этим мы, руководители проектов и команд, учились работать последние два года.<\/p>\n<h2>Третья волна<\/h2>\n<p>И вот сейчас я наблюдаю третью волну. Люди научились работать в командах, но только в узких рамках — нестандартные ситуации, которые раньше развивали команду за счет брейнштормов и новых интересных решений, теперь часто ставят команду в тупик. Доходит до того, что программисту проще сменить работу, чем разбираться со старой сложной задачей, требующей большого взаимодействия. Мы стали слишком однобоко, плоско, видеть своих коллег.<\/p>\n<p>Эволюция сотни тысяч лет готовила наш мозг к тому, чтобы изучать других, чтобы сделать их поведение более предсказуемым. Мы комфортно ощущали себя в своем племени, видели соплеменников каждый день в разных жизненных ситуациях. А сейчас мы видим коллег плоско — только на экране, только в рамках конкретных задач, только в контексте рабочих проблем. Это мешает нам обрести синергию.<\/p>\n<h2>Тибилдинговый булшит<\/h2>\n<p>Не я один пришел к подобному выводу. Компании стали больше обращать внимание на корпоративы, стараться собирать людей в офлайне. Но вот беда — часто это не дает желаемого результата. Олдскулл корпоратив в виде застолья с алкоголем, в этом плане, самый плохой вариант. Он показывает нам людей только в одной не слишком типичной ситуации, да еще и с измененным сознанием. Варианты со спортивными играми, квизы и настолки — значительно лучше, ведь показывают нам людей более объемно. В играх есть результат, дедлайн, взаимодействие в том или ином виде. Но набор разных ситуаций сильно ограничен, а участие конкретного члена команды сильно зависит от его знаний или физического развития.<\/p>\n<h2>НРИ<\/h2>\n<p>И вот тут пришло время упомянуть НРИ, то есть <a href=\"https:\/\/dtf.ru\/boardgames\/117049-s-chego-nachat-puteshestvie-po-nastolnym-rolevym-igram\">настольные ролевые игры <\/a>. Ведущий (Гейм Мастер) создает мир — описывает его правила, текущее состояние. Представляет персонажей фигурками на столе, рисует карту. А каждый игрок вживается в персонажа — это может быть волшебник или хоббит, космический пират или киборг. Это как RPG. Самая известная из таких игр Подземелья и драконы, сокращенно  <a href=\"https:\/\/dtf.ru\/boardgames\/912224-poigrali-vo-vse-nastolki-dungeons-and-dragons-vashe-spasenie-chto-eto-i-pochemu-vam-obyazatelno-stoit-v-nee-poigrat\">DnD<\/a>.<\/p>\n<p>Ролевки дают возможность попробовать себя в совершенно новом амплуа. И не просто попробовать, а действовать — разгадывать загадки, побеждать врагов, выбираться из лабиринтов. При этом взаимодействовать с персонажами других игроков, персонажами ведущего и миром. Это дает возможность посмотреть на свою команду в совершенно разных обстоятельствах. Всей команде предстоит действовать в новых условиях, самим выбирать себе цели и способы их достижения.<\/p>\n<h2>Дисклеймер<\/h2>\n<p>Не каждая такая игра подойдет для вас. Не все принимают игры и не все готовы погружаться в мир фантазий с головой. Мир НРИ огромен и создан гиками для гиков, поэтому важно, что ваш Гейм Мастер хорошо понимал что он делает и для кого. Я бы с удовольствием сделал пост с советами для корпоративного ГМа, но не совсем уверен, что он уместно на этом канале.<\/p>\n<h2>Результат<\/h2>\n<p>Если команда, в целом, дружна, но проблемы третьей волны все же чувствуются, то этот путь для вас. Опытный гейм мастер, который понимает что он делает и зачем сможет добиться результата, который вас поразит. Коллеги, знакомые друг с другом только в очень ограниченной среде вдруг узнают друг о друге очень много. И не в виде фактов, а в виде примеров, как человек может действовать в разных ситуациях, о чем думает, как договаривается.<\/p>\n",
            "date_published": "2022-01-29T18:16:16+05:00",
            "date_modified": "2022-09-27T16:47:42+05:00",
            "_date_published_rfc2822": "Sat, 29 Jan 2022 18:16:16 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "37",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "36",
            "url": "https:\/\/koreysha.ru\/?go=all\/kak-sdelat-processy-prozrachnee\/",
            "title": "Как сделать процессы прозрачнее?",
            "content_html": "<p>Предположим, вы пришли руководить проектом, но не понимаете что тут происходит. Кто-то пишет какой-то код, где-то появляются какие-то отчеты. К вам уже приходят с разными проблемами, а вы даже не понимаете в чем вопрос. Вы не можете понять движется ли вообще проект вперед или просто все бегают по кругу. Все это признаки того, что процессы максимально не прозрачны.<\/p>\n<h2>Так пусть говорят что делают<\/h2>\n<p>В первую очередь, такая ситуация лишает вас рычагов управления — непонятно, как на проекте скажутся те или иные действия, непонятно какие управленческие решения нужно принимать и как их потом внедрять. И первое, что приходит в голову — давайте всех остановим и заставим объяснять каждый свой шаг, докладывать о каждом действии, давайте каждое утро и каждый вечер будем проводить миттинг и подробно разбирать каждый вздох. К чему это приведет? К парализации всего процесса. У вас и так много задач и мало ресурсов, а тут вы еще грузите команду непосильной ношей отчетности. Что же делать?<\/p>\n<h2>Найти виноватого<\/h2>\n<p>Шучу, конечно. Это как раз не поможет точно. Тем более, что виноватых может и не быть вовсе. Любые процессы имеют тенденцию деградировать — это их общее фундаментальное свойство. Если вы настроили какую-то систему, а потом отпустили рычаги управления и оставили вариться в своем соку, то рано или поздно, но все вернется к хаосу. Это энтропия, которая всегда растет.<\/p>\n<p>Более того, желание найти виноватого есть не только у вас. Если спросите свою команду, то у каждого есть объяснение — плохой предыдущий руководитель; плохой бэкенд\/фронтэнд\/дизайн — ничего не успевают; ужасно сложный проект за очень мало денег, поэтому ни на что не хватает. И любая из этих убежденностей, не зависимо от того, полностью она высосана из пальца или имеет под собой какую-то основу, портит ваши процессы еще больше. Отбросить контекст в один момент не получится. О том, как над этим работать, поговорим в другой раз.<\/p>\n<h2>С чего начать?<\/h2>\n<p>Начните с поиска того процесса в проекте, который и так происходит и оставляет следы. Например, это могут быть пул-реквесты для команды разработки — они происходят и так, а в Гитхабе\/Гитлабе\/Битбакете есть все инструменты, чтобы видеть сколько их выставлено, сколько открыто и сколько прошло. В других ситуациях, это могут быть новые макеты, которые появляются. Или тест-кейсы. Методы АПИ, если они заносятся в Постман\/Сваггер. Любой из этих процессов можно достаточно просто привязать к прогрессу — попросить выбрать какой-то нейминг, чтобы вы понимали что это за реквест\/метод\/макет\/кейс. Можно на первом этапе перейти на язык этих метрик — «когда ты сделаешь пул-реквест» вместо «когда будет готова такая-то фича».<\/p>\n<p>Это скользкая дорожка — она может лишить команду ответственности. «Ну я же сделал реквест, я не виноват, что его не приняли». Но иногда этот метод может помочь проявить контуры того, что происходит без серьезных затрат. Увлекаться им не стоит, конечно. Хотя в будущем хороший нейминг и реквест-ориентированное планирование может нам сильно помочь сделать следующие шаг.<\/p>\n<h2>Окунитесь в проект<\/h2>\n<p>Второй метод, который я предлагаю — нырнуть с головой в какую-то задачу. Прямо закатать рукава и взяться запилить фичу. Не обязательно самому и в одиночку — можно в паре с разработчиком\/дизайнером. Но обязательно поучаствовать в каждом этапе. Смысл этого упражнения совсем не в том, чтобы ускорить проект за счет личного вклада. А в том, чтобы пройти самому по всему процессу и понять, как можно с наименьшими затратами сделать результат очевидным. Часто оказывается, что коммиты\/ветки\/реквесты\/макеты\/кейсы легко привязываются к задачам. И вот уже у нас есть шанс из предыдущего состояния «слежу, за чем могу» перейти к отслеживанию задач.<\/p>\n<h2>Дробите задачи<\/h2>\n<p>Идеальная задача занимает суммарно от 2-х до 6-ти часов. Но при этом имеет самоценность и видимый результат. Это не так мало, чтобы потонуть в потоке, ведь получается что в неделю один человек делает около десятка задач такого размера — это количество вполне может поместиться в “оперативной памяти”. Ну а команда из пяти-семи человек вполне сможет пройтись по списку недельных задач за час в формате «что-как-когда-какой результат».<\/p>\n<p>При этом, такой размер задач позволит делать в рамках одной задачи не более одного переноса со дня на день, а больше половины задач вообще такого разрыва иметь не будут. Это дает много преимуществ. Исполнителю не приходится долго восстанавливать контекст. А постановщику задачи проще контролировать актуальный список раз в день и сразу видеть проблемные задачи — те, которые не были закрыты в течение суток.<\/p>\n<h2>Упростите митинги<\/h2>\n<p>И последний совет на сегодня — постарайтесь упростить подготовку к встречам для вашей команды. Скорее всего, сразу настроить работу так, чтобы она стала истинно асинхронной, у вас не получится и все равно придется периодически устраивать общий созвон для всей команды. Ваша задача, как руководителя проекта, сделать так, чтобы сам созвон был максимально коротким и информативным, при этом требовал минимальной подготовки от команды. Для этого:<\/p>\n<ul>\n<li>Введите регламент. Он должен быть реалистичным и вам придется следить за его выполнением<\/li>\n<li>Автоматизируйте сбор необходимо информации ко встрече. Например, настройте отдельную доску в Джира куда автоматом будет собираться вся информация, нужная на созвоне<\/li>\n<li>Если вопросы, которые вы будете задавать требуют обдумывания, то вышлите их адресно и заранее. По возможности, вместе с вопросом пришлите заготовку ответа — так исполнителю будет проще понять чего вы от него хотите<\/li>\n<li>Не допускайте споров<\/li>\n<\/ul>\n<p>Это не все методы, которые я использую, чтобы сделать проект прозрачнее, но предлагаю начинать именно с этого.<\/p>\n",
            "date_published": "2022-01-22T20:36:24+05:00",
            "date_modified": "2022-01-29T18:17:06+05:00",
            "_date_published_rfc2822": "Sat, 22 Jan 2022 20:36:24 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "36",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "35",
            "url": "https:\/\/koreysha.ru\/?go=all\/kak-ya-diagnostiruyu-proekty-esli-oni-boleyut\/",
            "title": "Как я диагностирую проекты, когда они болеют",
            "content_html": "<p>Cегодня я хочу предложить порядок действий, которые помогут диагностировать проблему управления.<\/p>\n<h2>Don`t panic<\/h2>\n<p>Первым шагом предлагаю выполнить совет с обложки самоучителя «Автостопом по галактике». Худшее что можно сделать — начать паниковать и принимать кучу решений в попытке наверстать упущенное. Поспешные действия точно не помогут, зато легко могут все усугубить.<\/p>\n<h2>Команда<\/h2>\n<p>Я предпочитаю общаться с командой в формате один на один с каждым человеком. Важно, с одной стороны, не переходить на обсуждение конкретных текущих задач и, конечно, не переходить на обвинения. С другой стороны, не путать эту встречу с регулярными 1on1-ами, где центральной темой является личный рост и развитие.<\/p>\n<p>Нужно получить список всех проектных проблем, которые видит каждый член команды. Если есть предложения по решениям, их нужно выслушать и задокументировать. Очень часто, члены вашей команды уже знают что нужно делать и сами подскажут все необходимые шаги. Столь же часто их взгляд может оказаться однобоким и решение улучшит что-то в одном месте, но сделает хуже в другом. Поэтому наша цель на этом этапе — собрать максимум информации. А принимать решение позже.<\/p>\n<h2>Проектные решения<\/h2>\n<p>В рамках того, что уже сделано, принято немало проектных решений. Некоторые из них были удачными, другие — не очень. Хорошо бы вновь пробежаться свежим взглядом по тем решениям, которые были приняты и  верхнеуровнево задокументировать их для себя заново.<\/p>\n<p>Под такими решениями я понимаю, например, текущую архитектуру сервиса. Опору на внешние источники или зависимости. Договоренности о взаимодействии частей системы друг с другом, API, SOAP и т.д.<\/p>\n<p>Конечно, я не предлагаю все переписать на новом молодежном фраемворке. Но часто описание проектных решений в едином документе помогает обнаружить проблему. Еще чаще проблемой является сам факт того, что решение нигде не описано.<\/p>\n<h2>Процессы<\/h2>\n<p>Чтобы найти проблемы в процессах, их нужно сделать настолько прозрачными, насколько возможно без изменения бюджета на управление процессами. Можно, конечно, заставить всю команду собираться трижды в день и отчитываться о промежуточных итогах — но это огромные издержки по времени. Нужно использовать максимально «дешевый» способ сделать процессы прозрачнее. О том как именно это сделать напишу в другой раз.<\/p>\n<h2>Задача<\/h2>\n<p>Когда составлен реестр проблем и неоптимальных решений. Когда выписаны все сложности в команде. И понятно, где застревают процессы. В этот момент стоит обратиться к изначальной задаче, которую решает проект. Понимание задачи может помочь посмотреть на свой список свежим взглядом. А еще напомнит нам ограничения, которые есть на самом фундаментальном уровне.<\/p>\n<h2>Риски<\/h2>\n<p>Последним шагом краткого аудита процессов я предлагаю заново оценить риски. Часть из них были известны еще до старта проекта, а часть оказались очевидными сейчас. Именно оценка рисков позволит понять какие действия требуются в первую очередь, а какие можно отложить.<\/p>\n<p>И особенно важно найти самые серьезные риски по вероятности и по значимости. Часто исправления процессов стоит начинать именно с купирования самых серьезных  рисков. Бывает, что вопреки всему, стоит прямо сейчас провести рефакторинг ключевого решения или заменить его на готовую библиотеку, несмотря на то, что это может задержать проект.<\/p>\n<h2>Итоги<\/h2>\n<p>“И это все?” спросит внимательный читатель. Конечно, нет. Все проекты разные. Но эти шесть шагов, на мой взгляд, самый минимальный набор действий, которые стоит совершить до того, как можно садиться за анализ и делать какие-то выводы. Если пропустить какой-то из них, то это почти гарантированный способ не починить процессы, а сломать все еще больше.<\/p>\n<p>Если проект небольшой, например, не более 10 человек готовили проект около полугода. То такой анализ можно сделать в одиночку за одну-две недели. С минимальным отрывом текущей команды о работы. Ну а дальше уже принимать управленческие решения.<\/p>\n",
            "date_published": "2021-12-21T17:18:27+05:00",
            "date_modified": "2021-12-21T17:18:59+05:00",
            "_date_published_rfc2822": "Tue, 21 Dec 2021 17:18:27 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "35",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "34",
            "url": "https:\/\/koreysha.ru\/?go=all\/paradoksalno-no-dobaviv-esche-paru-razrabotchikov-vy-ne-razgruzi\/",
            "title": "Парадоксально, но добавив еще пару разработчиков, вы не разгрузите команду",
            "content_html": "<p>Представим такую ситуацию в проекте: задач много; команда зашивается; некогда думать и нужно фигачить; до дедлайна время ещё есть, но уже видно, что его недостаточно. Если вам это знакомо, то, вероятно, вы думаете, что вам не хватает парочки сильных мидлов в команду прямо сейчас. Но, скорее всего, это не так. И расширяя команду, вы сделаете только хуже.<\/p>\n<h2>Краткосрочная перспектива<\/h2>\n<p>Новые люди в проекте затормозят его, а не ускорят. Есть даже шутка: что 2 программиста сделают за 2 дня, то 4 программиста сделают за 4 дня.<\/p>\n<p>Во-первых, новых разработчиков нужно погружать в контекст. Показывать особенности ваших процессов, вводить в доменную область, разбираться в архитектуре проекта. Это ещё если нет никаких расхождений по стеку и других сложностей. Причем, нужны не только время и силы «новичков», но и ресурсы команды.<\/p>\n<p>Во-вторых, мы увеличиваем количество связей между людьми. Напомню, что оно растет экспоненциально. Для команды из 5 человек – 10 попарных связей, а для 7 уже 21 связь. Команде нужно общаться. Если вы думаете, что у вас схема «звезда», когда каждый разработчик взаимодействует только с PM-ом, то, скорее всего, вы ошибаетесь. В сложных, не детерминированных изначально системах, где в процессе работы принимаются проектные решения, попарное взаимодействие необходимо.<\/p>\n<p>В-третьих, размывается ответственность. У «старичков» есть повод спихнуть «душные» задачи и немного расслабиться. Ну а «новички» пока слабо владеют контекстом и морально не принимают на себя ответственность за весь проект в целом. Это происходит даже тогда, когда команда сильно мотивирована. А в нашем случае, вероятно, с мотивацией уже есть проблемы.<\/p>\n<h2>Среднесрочная перспектива<\/h2>\n<p>«Хорошо» — скажет внимательный читатель. Но ведь все это пройдет через месяц-другой. Если сроки позволяют, то почему бы и не расширить команду?<\/p>\n<p>Но за первой волной проблем, придет вторая. У большой команды, окажется, что все не мержится так легко, без единого конфликта, как все привыкли. Код ревью, который был в ответственности одного тимлида становится узким горлышком. Фичи не дробятся на 5 частей так легко, как дробились на две. Короче, всплывут проблемы в организации процесса, которые раньше никого не волновали. И их придется решать, а это дополнительная работа.<\/p>\n<h2>Долгосрочная перспектива<\/h2>\n<p>«Ну хорошо» — скажет мой воображаемый оппонент — «Но ведь и эти все вопросы решатся, уж через полгода то у нас будет более сильная команда?». И я отвечу что да, будет. Но есть и другая беда — эта более сильная команда будет дороже стоить. Причем не только на сумму зарплаты новых разработчиков. Добавятся накладные расходы, вырастут потери из-за новых процессов. В итоге, бизнес захочет, чтобы эта новая команда делала больше работы. Ну и мы автоматически вернулись в точку А, только теперь в чуть большем масштабе.<\/p>\n<h2>Что же, выхода нет?<\/h2>\n<p>Просто мы изначально подошли к решению проблемы не стой стороны. Если у вас уже беда в проекте. Если разработчики жалуются, что им вздохнуть некогда. Если вся команда фигачит много, но до результата все дальше и дальше. Значит вы столкнулись с проблемой управления. А такая проблема не решается подкидыванием дров в топку, или, в нашем случае, программистов на проект. Такая проблема решается отстраиванием процессов. А вот как все это правильно диагностировать и что потом делать — предмет другого разговора.<\/p>\n<h2>Но ведь как-то команды растут?<\/h2>\n<p>Скептик может сказать, что я рублю с плеча. И, если бы все сказанное было правдой, то никакие команды никогда бы не росли. Но, во-первых, реальный рост команд действительно очень ограничен. И все крупные проекты, при достижении определенного масштаба не увеличивают команды до бесконечности, а дробят их на несколько.<br \/>\nХочу обратить внимание скептика, что я обозначил конкретные условия, в которых растить команду без предварительного изменения подхода к управлению, на мой взгляд, плохой план. В других случаях, рост команды не просто возможен, но, иногда, и необходим. Но их мы обсудим отдельно, если будет такое желание.<\/p>\n",
            "date_published": "2021-12-21T17:16:18+05:00",
            "date_modified": "2021-12-21T17:16:11+05:00",
            "_date_published_rfc2822": "Tue, 21 Dec 2021 17:16:18 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "34",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "25",
            "url": "https:\/\/koreysha.ru\/?go=all\/esche-nemnogo-o-udalennoy-rabote\/",
            "title": "Еще немного о удаленной работе",
            "content_html": "<p>Постоянно слышу о том, как круто, когда все работают удаленно. Периодически читаю <a href=\"http:\/\/blog.skaplichniy.ru\/all\/jobbing\/\">посты в блогах<\/a>, а иногда, даже <a href=\"http:\/\/www.mann-ivanov-ferber.ru\/books\/paperbook\/remote-office-not-required\/?buytab=ebook\">целые книги<\/a> попадаются. Иногда, у меня возникает ощущение, что я живу в каком-то параллельном мире.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/koreysha.ru\/pictures\/job-1257204_1920.jpg\" width=\"1920\" height=\"638\" alt=\"\" \/>\n<\/div>\n<p>Вот приходит сотрудник и говорит: «Ребята, хватит жить в прошлом веке. Есть скайп, почта и телефон. Я могу брать задачи и выдавать результат, зачем мне каждый день терять два часа в пробках?» Решили попробовать. Договорились, что пока не каждый день, но некоторые дни работать удаленно.<\/p>\n<p>И вот первый же «тестовый» день. Мелкий вопрос мы обсуждали письменно в скайпе полтора часа (с перерывами на 3-5 минут), тогда, как очно ушла бы пара минут. Просьбу «сделать более подробное описание» в одной из задач нашего таск-менеджера сотрудник выполнить не смог, так как был страшно занят. Отчет, о котором мы договаривались так же подготовить не успел. А на следующий день пришлось потратить еще час, что бы узнать, чем занимался сотрудник. Выяснилось, что не тем.<\/p>\n<p>И, поймите меня правильно, я не виню конкретно этого человека. Мы отлично работали в команде в одном помещении. И я уверен, что тут не было какого-то злого умысла и, даже, банального распиздяйства. Просто не достаточно того факта, что у нас обоих есть скайп, что бы перейти к удаленной работе.<\/p>\n<p>Вы скажете, что я сам дурак. Ну зачем было переписываться полтора часа, когда можно позвонить? Да по тому, что сразу это не очевидно. Я не думал, что маленькая сложность может вызвать такие затруднения. Да и неправильно понятая фраза завела разговор в тупик дважды.<\/p>\n<p>И я не против такой системы работы в целом. Просто считаю, что она не всем подходит. Например, про себя я знаю, что если есть одна большая задача, то без проблем смогу работать удаленно. Смогу сделать результат своей работы очевидным. Смогу показывать прогресс в недельной задаче и «прибивать гвоздями» ключевые точки. Но решить 10 мелких операционных вопросов за день удаленно я не смогу. А если смогу, то разгребать непонятки еще неделю потом.<\/p>\n<p>При этом, у нас есть другой сотрудник, который успешно работает из другого города. и проблем не возникало ни разу. В чем секрет?<\/p>\n",
            "date_published": "2016-04-21T18:35:19+05:00",
            "date_modified": "2016-04-21T18:35:11+05:00",
            "image": "https:\/\/koreysha.ru\/pictures\/job-1257204_1920.jpg",
            "_date_published_rfc2822": "Thu, 21 Apr 2016 18:35:19 +0500",
            "_rss_guid_is_permalink": "true",
            "_rss_guid": "https:\/\/koreysha.ru\/?go=all\/esche-nemnogo-o-udalennoy-rabote\/",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/koreysha.ru\/pictures\/job-1257204_1920.jpg"
                ]
            }
        },
        {
            "id": "18",
            "url": "https:\/\/koreysha.ru\/?go=all\/kak-my-vvodili-git\/",
            "title": "Как мы вводили git",
            "content_html": "<p>Git — это одна из популярных систем контроля версий. Код — это, прежде всего, текст. Такой текст, который правят многократно и по чуть-чуть в разных местах. Хранить только последнюю версию кода не дальновидно, по тому, что часто какие-то правки приходится отменять, а в каких-то случаях надо посмотреть «как оно работало раньше». Хранить каждую новую версию кода, то есть копировать всю директорию, допустим раз в день, не удобно по двум причинам: во-первых, занимает много места, а во-вторых, не дает никакого понимания о том, что именно изменилось.<br \/>\nУмные программисты придумали решение этих проблем. Оно заключается в том, что бы хранить какую-то базовую версию, а после сохранять только маску изменений. Например, мы храним 1000 строк кода и после изменений запоминаем, что поменялись 387 строка и 425.<br \/>\nТакое решение дало еще один неожиданный плюс. Оно позволило работать над одним и тем же кодом разным людям одновременно. Первый программист поменял вторую, третью и четвертую строку, а второй — девятую и десятую. Система сама поняла, что может применить к начальному коду и те изменения и эти. И только, если возникнет конфликт, придется разруливать людям.<\/p>\n<h2>Америка<\/h2>\n<p>Впрочем, если вы так или иначе связаны с разработкой программного обеспечения, скорее всего, Америку я вам не открыл. Во всем мире различные системы контроля версий — неотъемлемый атрибут любого программиста. Читая профессиональные форумы, блоги известных web-разработчиков и доклады с различных конференций сложно себе представить, что кто-то может жить без git-а или svn-а. Однако, в наших реалиях куча небольших веб студий и одиночек-фрилансеров работают «по-старинке». Так получилось, что и я на первых своих местах работы с системами контроля версий познакомился только заочно. До сих пор стыдно признаться, что несколько лет я писал код без таких систем.<br \/>\nВпрочем, я был такой не один. И так получилось, что у нас собралась команда из четырех человек, где никто полноценно с контролем версий не работал. У меня был до этого опыт, где все настроили до меня и оставалось только коммитить, то есть записывать изменения которые я внес. Еще у двоих членов команды был подобный опыт. Однако никто из нас не представлял, как полностью должна работать система от компьютера программиста до «боевого сервера».<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/koreysha.ru\/pictures\/git.png\" width=\"1920\" height=\"1280\" alt=\"\" \/>\n<\/div>\n<p>Как ни странно, гугление не могло ответить на те вопросы, которые возникали у меня в первую очередь. Например гугл на вопрос «<a href=\"https:\/\/www.google.ru\/?gws_rd=ssl#newwindow=1&q=%D0%BA%D0%B0%D0%BA+%D1%81%D0%BC%D0%B5%D1%80%D0%B6%D0%B8%D1%82%D1%8C+%D0%B2%D0%B5%D1%82%D0%BA%D0%B8+git\">Как смержить ветки git<\/a>» дает около 700 результатов и вся первая страница по делу. А на запрос «<a href=\"https:\/\/www.google.ru\/?gws_rd=ssl#newwindow=1&q=git+%D0%BB%D0%BE%D0%BA%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE+%D0%B8%D0%BB%D0%B8+%D0%BD%D0%B0+%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B5\">git локально или на сервере<\/a>» дает 275 тыс ответов и я не смог найти что-то в тему.<\/p>\n<h2>Наши правила<\/h2>\n<p>Многое мне было непонятно. Но в итоге чтения кучи статей и советов я принял ряд решений.<\/p>\n<ol start=\"1\">\n<li>Мы отказались от гита локально на каждом компьютере разработчика. Вместо этого, мы используем IDE и копию проекта на нашем сервере. У каждого разработчика есть своя локальная копия и своя удаленная копия. Уже на сервере стоит гит и туда надо зайти что бы провести с ним какие-то операции. Такое решение я принял по целому ряду причин. Основная причина в том, что мы взяли курс на проекты выше среднего по сложности и настраивать у каждого разработчика веб-сервер с нужными пакетами в условиях разных ОС и различной удаленности друг от друга сложная задача. А внедрить все это надо было без ущерба для производства.<\/li>\n<li>Никаких встроенных в IDE систем поддержки git и других «улучшителей вкуса» мы решили не использовать. Во-первых, в нативных командах из консоли нет ничего, чему нельзя научить за пару дней. А во-вторых, меня однажды такая система поддержки сильно подвела — вывела совсем не то, что произошло на самом деле.<\/li>\n<li>Мы ввели правило одна задача — одна ветка. Коммитов в нее может быть много, но чаще 1-2. Сливаем изменения только после завершения задачи.<\/li>\n<li>Все, что не касается напрямую нашего кода мы стараемся исключить из системы контроля версий. С этой задачей до сих пор справляемся хуже всего.<\/li>\n<li>Ввели правило «сервера для тестирования». Каждый раз после сливания изменений от разных разработчиков сайт поступает на тестирование и только потом выходит в продакшн, как бы не торопил заказчик.<\/li>\n<li>Мы стали использовать git в связке с Bitbucket. Система контроля версий без удаленного репозитория и в половину не так хороша. Но это, наверное, тема для отдельной заметки.<\/li>\n<\/ol>\n<h2>И все пошло, как по маслу?<\/h2>\n<p>В начале было очень тяжко. Постоянно забывали новую схему работы и то вносили какие-то правки прямо на «живом сервере», то забывая про это пытались залить туда изменения с сервера разработки. Постоянно получали конфликты и не понимали, как их решать. Самое сложное было постоянно заставлять всех работать только через систему контроля версий. Каждый раз хотелось «сделать последний разок по-простому». И каждый раз приходилось останавливать и себя и команду.<\/p>\n<p>С тех пор прошло уже достаточно много времени, и я теперь я с уверенностью могу сказать, что это было одно из самых правильных управленческих решений. Сколько раз спасала нас эта схема сложно описать. Сколько недовольства клиентов мы смогли избежать за счет аккуратного подхода к переносу на «боевой», трудно себе даже представить.<\/p>\n<p>А какую систему контроля версий используйте вы? И какие сложности были с её внедрением?<\/p>\n",
            "date_published": "2016-01-15T22:10:04+05:00",
            "date_modified": "2016-01-15T22:09:38+05:00",
            "image": "https:\/\/koreysha.ru\/pictures\/git.png",
            "_date_published_rfc2822": "Fri, 15 Jan 2016 22:10:04 +0500",
            "_rss_guid_is_permalink": "true",
            "_rss_guid": "https:\/\/koreysha.ru\/?go=all\/kak-my-vvodili-git\/",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/koreysha.ru\/pictures\/git.png"
                ]
            }
        },
        {
            "id": "17",
            "url": "https:\/\/koreysha.ru\/?go=all\/knigi-o-samyh-poseschaemyh-saytah-v-runete\/",
            "title": "Книги о самых посещаемых сайтах в рунете",
            "content_html": "<p>На Новый год мне подарили две книги: <a href=\"http:\/\/www.ozon.ru\/context\/detail\/id\/27597188\/\">Яндекс.Книга<\/a> и <a href=\"http:\/\/www.ozon.ru\/context\/detail\/id\/19361452\/\">Код Дурова<\/a>. До того, как я их открыл и прочитал для меня между ними было много общего. Сегодня будет экспериментальный пост-рецензия.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/koreysha.ru\/pictures\/DSC_1003.JPG\" width=\"1725\" height=\"1044\" alt=\"\" \/>\n<\/div>\n<h2>Яндекс.Книга<\/h2>\n<p>В каждом, самом незначительном, аспекте книги, от обложки до верстки, от структуры повествования до построения фраз чувствуется, что автор проникся особым духом компании Яндекс. Книга рассказывает о том, что наш поисковик №1 совсем не калька с Гугла, и заставляет поверить, что где-то на постсоветском пространстве остались еще светлые головы.<br \/>\nПосле прочтения я для себя вынес, что<\/p>\n<ol start=\"1\">\n<li>У прорывных проектов нет простых времен. Каждый этап развития это битва за выживание.<\/li>\n<li>Возможно делать продукты для людей и при этом зарабатывать деньги. До этого меня периодически одолевали сомнения — будет ли в нашей стране жить бизнес, в котором не надо будет каждый день идти против себя и считать своих клиентов биомассой.<\/li>\n<li>Кадры решают все. В дальней перспективе сильная команда с единым «вектором развития» важнее, чем деньги, связи, клиенты и все остальное.<\/li>\n<\/ol>\n<p>Периодически в книге проскакивают решения, принятые Аркадием Воложем вопреки внешним обстоятельствам. Или такие на которых настоял Илья Сегалович, хотя на момент принятия они совсем не казались очевидными. Но в отличает от «Кода Дурова», читатель четко понимает, что у основателей Яндекса была своя философия и в её рамках все закономерно.<\/p>\n<p><b>Стоит прочесть<\/b> всем, кто ведет бизнес в России; всем, кто хоть отдаленно связан с IT; всем, кто управляет хотя бы маленькой командой; всем, у кого есть конкуренты; всем кому интересно, что у нас все еще есть чем удивить запад.<br \/>\n<b>Не стоит читать<\/b> только если вы не верите в людей, в страну, в идеи и ненавидите все это.<\/p>\n<h2>Код Дурова<\/h2>\n<p>Прежде, чем высказать свое мнение об этой книге оговорюсь, что я знаком с действиями Павла Дурова только по ней и редким отголоскам СМИ, которые до меня долетали. По этому все, что я буду о нем говорить относится только к персонажу книги, но никак не к реальному человеку.<br \/>\nКнига о том, как самовлюбленный мажор, который верил в свое величие и успех со школьной скамьи, без особых усилий и со скромными познаниями в программировании строит виртуальную империю. При этом у нег нет сильных компаньонов — все они оказываются мелочными, меркантильными и недальновидными. У него нет сильной команды — единственный программист о котором книга отзывается хорошо бежал из компании «вконтакте» при первой же возможности.<br \/>\nАвтор называет основателя соцсети не иначе, как «тотем». Реже «архитектор». Все решения, которые «тотем» принимает приходят к нему свыше и никак не согласуются с реальностью. При этом, главный герой умудряется просто так без веских причин и без нужны в инвестициях продать большую долю Мильнеру, что в итоге приводит к тому, что компанию у него планомерно отжимают. Сам же Павел ведет себя, как истеричка, то выкладывая фото с «факом» после деловых переговоров, то намеренно провоцируя государство. После последнего он, кстати, выходит сухим из воды, просто не открыв дверь ОМОНУ.<br \/>\nПрочитав эту книгу тебе кажется, что:<\/p>\n<ol start=\"1\">\n<li>Адекватные деловые решения не нужны. Стартап вырастет сам, если ты гений.<\/li>\n<li>Когда тебе хочется без причин плевать на пользователей ты можешь это делать. А когда на тебя будут давить сверху ты можешь просто показывать фак и говорить, что пользователи не поймут, если ты закроешь группу Навального.<\/li>\n<li>Если у тебя проблемы, просто психуй, бросай компанию и берись за разработки совершенно в другой области, по тому что ты гений и новый стартап взлетит так же, как и старый.<\/li>\n<\/ol>\n<p><b>Стоит прочесть<\/b> тем, кто в восторге от «Вконтакте» и считает его скорее божественным провидением, чем земным созданием.<br \/>\n<b>Не стоит читать<\/b> если вы верите в здравый смысл в бизнесе.<\/p>\n",
            "date_published": "2016-01-08T20:56:04+05:00",
            "date_modified": "2016-01-08T20:55:56+05:00",
            "image": "https:\/\/koreysha.ru\/pictures\/DSC_1003.JPG",
            "_date_published_rfc2822": "Fri, 08 Jan 2016 20:56:04 +0500",
            "_rss_guid_is_permalink": "true",
            "_rss_guid": "https:\/\/koreysha.ru\/?go=all\/knigi-o-samyh-poseschaemyh-saytah-v-runete\/",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/koreysha.ru\/pictures\/DSC_1003.JPG"
                ]
            }
        },
        {
            "id": "11",
            "url": "https:\/\/koreysha.ru\/?go=all\/malenkiy-komponent-v-bolshoy-proekte\/",
            "title": "Маленький компонент в большом проекте",
            "content_html": "<p>Сегодня я хочу поделиться реальным кейсом, в котором показать, как планируется работа над конкретным компонентом, и как требования к нему меняются прямо во время разработки.<br \/>\nМоя история будет про небольшой компонент крупного проекта, на примере которого я постараюсь показать, какие метаморфозы происходят с задачей в процессе работы и что сделать, что бы эти изменения не затянули проект до бесконечности. Сроки, которые я укажу носят условный характер.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/koreysha.ru\/pictures\/the-strategy-1080527_1920.jpg\" width=\"1920\" height=\"1277\" alt=\"\" \/>\n<\/div>\n<p>Проект представляет из себя интернет-магазин, в котором, по предварительным нашим прикидкам должно получится около 100 групп товаров, распределенных, в среднем, по трем уровням вложенности. Товаров в каждой группе, так же предполагается существенное количество.<br \/>\nНа этапе проектирования мы прописали несколько основных сценариев, как пользователь сможет найти нужный ему товар. Вместе с заказчиками мы описали основной сценарий: пользователи будут находить нужную группу товаров, а дальше искать товар, который их интересует по ряду параметров. В зависимости от того, какая это группа, а так же задач  пользователя, его будут интересовать разные параметры. Кого-то размеры: ширина, высота, объем; кого-то цвет и фактура; а кого-то цена и бренд. Все варианты перечислить очень трудно, а учесть в техническом задании и подавно.<br \/>\nПараметры, по которым можно будет искать товар мы назовем свойства или характеристики. О них и пойдет речь.<\/p>\n<h2>Начинаем работу<\/h2>\n<p>Работа начинается с того, что проектировщик, описывает модуль. А позже, вместе с программистами, оценивает его по срокам и включает в общую оценку проекта. Начал проектировщик с того, что записал, все, что ему известно о свойствах товаров нашего проекта.<\/p>\n<ol start=\"1\">\n<li>У каждого товара может быть мало (3-4) или много (10-15) различных характеристик.<\/li>\n<li>Характеристики почти полностью повторяются внутри группы товаров. То есть, если у одного “метиза” есть диаметр, длинна и шаг резьбы, то у другого, скорее всего, то же. Группа верхнего уровня может включать или не включать эти характеристики.<\/li>\n<li>У разных групп товаров свойства могут быть совсем разные. Однако, часто можно выделить блоки характеристик. Такие блоки полностью повторяются у одних групп товаров и отсутствуют у других. Большинство блоков “наследуются” в дочерних группах, но иногда появляются только в конечной группе. Например блок, который можно назвать “размеры” (ширина, высота, длинна) есть и у москитных сеток и у дюбелей, но совершенно не важен для монтажной пены или клея.<\/li>\n<\/ol>\n<h2>С другой стороны<\/h2>\n<p>Одновременно с работой проектировщика, свою работу над характеристиками начала дизайнер проекта. Она изучила множество отечественных и зарубежных интернет магазинов, а так же ассортимент нашего заказчика. Выяснила, что пользователю, как правило, удобно выбирать из представленных вариантов (белый, черный или коричневый цвет), либо указывать диапазон значений (цена от 100 до 300 рублей). Другие варианты подбора по параметрам в этой отрасли встречаются реже. Из этого понимания появился дизайн-макет фильтров на странице группы товаров.<br \/>\nЗаказчик согласует дизайн-макет и таким образом “бетонирует” решения дизайнера. Дальше от них отступать нельзя.<\/p>\n<h2>Пишем ТЗ<\/h2>\n<p>С оглядкой на дизайн-макет, проектировщик принимается, за написания технического задания. Ему нужно понять, в каком виде можно хранить информацию. “Любое свойство продукта состоит из пары ключ-значение.” – решает проектировщик, для начала. Название у характеристики есть всегда, а вот со значением несколько хитрее.<br \/>\nПо некоторым характеристикам нужно сделать возможность выбора диапазона – от максимального значения, до минимального. Такие свойства нужно явно задать числовыми, иначе мы не сможем проводить с ними математические операции, если пользователь введет что-то не числовое. Программисты попросили так же для увеличения производительности поделить числовые свойства на целые числа и дробные. А еще стало очевидно, что у числовых свойств будут еще единицы измерения. Так появились первые два типа характеристик.<br \/>\nПотом проектировщик стал обдумывать фильтры по таким свойствам, как цвет или тип крепления. Понятно, что можно дать администратору сайта вводить эти значения вручную, а пользователю потом предлагать выбрать из многих вариантов. Проектировщик уже имел опыт с таким решением и знал, что в этом случае скорее всего появятся такие варианты, как “Белый”, “белый‘, ‘светлый’, ‘белесый’, ‘white’. Все они, возможно, различаются для заполняющих сайт. но никак не различаются для пользователя. По этому нужно администратора ограничить. Пусть главный администратор вводит варианты цветов, а все остальные только выбирают из предложенного. Так мы избежим этой путаницы. Программисты так же отметили, что это целых два типа характеристик описано: в первом у товара есть только один вариант у списка(цвет только один), а во втором может быть несколько вариантов одновременно  (сразу несколько вариантов креплений).<br \/>\nИзучая другие магазины подобной тематики, проектировщик отметил, что есть свойства, у которых может быть только два значения: есть или нету. эти свойства он вынес в отдельный тип.<br \/>\nНу а все характеристики, которые нельзя будет отнести к этим типам оставим в виде текстового названия и текстового значения.<\/p>\n<p>Итого, оказывается, что всё многообразие свойств можно разделить  6 типов характеристик. Решено, что администратор сайта будет создавать список характеристик и задавать их тип. Для некоторых вводить так же единицы измерения и возможные значения.<br \/>\nЭто решение оценено в 25 часов работ программистов и верстальщиков. Руководитель проекта имеет немалый опыт и предлагает еще раз посмотреть на характеристики со всех сторон.<\/p>\n<h2>Смотрим со всех  сторон<\/h2>\n<p>Начнем оценку нашего решения со стороны разработчика. Давайте представим, что мы приступили к написанию поиска по характеристикам. Тут то и становится понятно, что всего в проекте предполагаются десятки тысяч характеристик и десятки тысяч товаров. А это значит, что при поиске по одной характеристики серверу предстоит обработать около ста миллионов операций сравнения. Кроме того, стоит учитывать, что пользователь может задать одновременно фильтр по многим характеристикам. А пользователей, надеемся, будет много. Выдержит ли сервер такие нагрузки? Предварительное нагрузочное тестирование показывает, что нет.<br \/>\nЗовем программистов на совет. Цель: не меняя дизайн макет и внешнюю структуру сайта что-то придумать с производительностью. Вместе они еще раз открывают список, составленный проектировщиком в самом начале и решают, что каждую характеристику можно отнести не ко всему интернет-магазину сразу, а только к конкретной группе товаров. Таким образом количество характеристик уменьшится до сотен и товары, среди которых стоит искать так же ограничатся одной группой, то есть то же порядок ‘сотни’. Так мы снизим количество операций с сотен миллионов до десятков тысяч. Правда, при таком решении предполагаемый срок разработки  увеличился до 40 часов.<\/p>\n<p>Теперь давайте посмотрим на наш план глазами администратора сайта. Руководитель проекта шутит, что через месяц заполнения сайта администратор придет к нам в офис с бейсбольной битой. ‘Почему? Да потому, что администратор сайта чекнется вносить длину, ширину и высоту, для нескольких десятков групп товаров. А цвет и бренд для всех почти.’ – говорит он. ‘И это еще пол беды. Допустим, есть две похожие группы ‘метизы’ и ‘дюбели’, в обеих есть длинна. Клиент хочет подобрать и то и другое под диаметр. Получается, вы его заставите сначала в одной группе фильтры забивать, потом в другой. Как ваша интеллектуальная система длину оттуда с длинной отсюда сопоставлять будет? ’.<br \/>\nМысль здравая. После тщательного обдумывания всех нюансов, принято решение разбить характеристики на блоки. А потом добавить возможность прикреплять эти блоки к разным группам товаров. Важно так же учесть, что у одной группы может быть любое число таких блоков. Оценка работ увеличилась до 60 часов.<\/p>\n<p>Вот теперь руководитель проекта с чистой совестью вносит 60 часов в общий срок и согласовывает его с заказчиком. Тут нужно отметить, что не всегда просто донести до заказчика все решения, которые приняты в проекте. Но это очень важно, по тому, что никто, не знает о товаре и покупателях столько, сколько заказчик. Ведь пока проектировщик учился составлять техническую документацию, а руководитель проекта учитывать все риски, заказчик вел свое дело и теперь является в нем экспертом высокого класса.<\/p>\n<h2>Новые фичи<\/h2>\n<p>Проект стартует и разработка идет своим чередом. На очередном совещании по сделанному, руководитель проекта предлагает добавить к текущему этапу выгрузку из складского учета (1с) заказчика. По тому, что иначе очень трудно будет понять какие функции сайта на реальных данных как себя ведут. Сроки на этот момент мы немного опережали и очень хотели порадовать заказчика дополнительным функционалом, который не должен был входить в этот этап.<br \/>\nПредполагается, что будут выгружены только структура групп товаров, названия товаров и их цена. Это предположение было предварительно согласовано с заказчикам еще до написания подробной документации. После чего, у заказчика запрашивается выгрузка всех его текущих товаров. Тут надо отметить, что в нам повезло: быстро удалось найти общий язык со специалистами 1с со стороны заказчика.<\/p>\n<p>Получив выгрузку, руководитель проекта просит встречи с клиентом для уточнения важных моментов о ценах на товары. Для единого понимания с обеих сторон, вся информация о товаре делится на шесть частей: группа, куда входит товар, характеристики, изображения, описание, остаток и особняком стоит цена. Структура групп товаров и наличие на складе, конечно, есть в системе складского учета заказчика. А вот с ценой все оказалось сложнее, но это выходит за рамки моего рассказа.<\/p>\n<p>В ходе переговоров принимается решение, что характеристики заказчик заполнит в своей системе складского учета. Это, конечно, автоматически добавляет работы по выгрузке характеристик в базу данных сайта и их дальнейшую синхронизацию. Внутренняя оценка работ возрастает до 80 часов. Но клиент очень важен для нас и мы принимаем решение сделать это в рамках того же бюджета. Договариваемся, что мы подготовим требования к структуре характеристик, которые подойдут для нашей системы, часть из которой уже разработана.<br \/>\nЧерез какое-то время, специалисты клиента просят составить формат выгрузки в котором сайту удобно было бы получать данные. Проектировщик на следующий день формат высылает. И тут выясняется, что система складского учета построена так, что не может обеспечить нужную структуру. Более того, так же нет деления на типы характеристик. Получится выслать только в виде название-значение.<\/p>\n<h2>И что будем делать?<\/h2>\n<p>Что ж, проект все равно делать надо. Проектировщик вместе с программистами придумывают «интеллектуальный» алгоритм, который пытается сам определить тип характеристики. Так же сам пытается отделить значение от единицы измерения или записать варианты значений. Реализация такого алгоритма увеличивает оценку до 100 часов.<br \/>\nТакое увеличение уже не взять на себя без потерь качества или диких срывов сроков и руководитель проекта это понимает. Теперь приходится вести переговоры с клиентом о том, что бы урезать какой-то менее важный компонент на первом этапе или увеличить общий бюджет этапа. Но это уже другая история.<\/p>\n<h2>Вместо итога<\/h2>\n<p>Каждая команда разработчиков сталкивается с подобными ситуациями, особенно в крупных проектах. Как бы ни был лоялен клиент и какой бы опыт ни был у разработчиков, избежать полностью таких ситуаций не удастся. Для себя мы сделали ряд выводов, которые минимизируют потери:<\/p>\n<ol start=\"1\">\n<li>Всегда прежде чем называть сроки\/стоимости клиенту возьмите паузу и еще раз взгляните на компоненты проекты со всех точек зрения. В нашем случае, это сторона программистов, сторона администратора сайта, сторона конечного пользователя-покупателя и сторона бизнеса, конечно. Не сделав этого, мы могли ошибиться в 4 раза.<\/li>\n<li>При ведении переговоров с клиентами старайтесь охватить все аспекты. Конечно, что-то учесть не удастся, но чем четче были обозначены ранее принятые решения, тем проще будет договариваться дальше.<\/li>\n<li>Старайтесь составить четкий чек лист, что бы клиент мог в любой момент видеть входит в данный этап, что что в последующие. В этом проекте мы этого не сделали и еще больше запутали клиента, когда брали на себя дополнительные обязательства по этапу. В дальнейшем постараемся прописывать и проговаривать все более четко.<\/li>\n<\/ol>\n",
            "date_published": "2015-12-13T17:34:28+05:00",
            "date_modified": "2015-12-13T19:18:50+05:00",
            "image": "https:\/\/koreysha.ru\/pictures\/the-strategy-1080527_1920.jpg",
            "_date_published_rfc2822": "Sun, 13 Dec 2015 17:34:28 +0500",
            "_rss_guid_is_permalink": "true",
            "_rss_guid": "https:\/\/koreysha.ru\/?go=all\/malenkiy-komponent-v-bolshoy-proekte\/",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/koreysha.ru\/pictures\/the-strategy-1080527_1920.jpg"
                ]
            }
        },
        {
            "id": "10",
            "url": "https:\/\/koreysha.ru\/?go=all\/cms-dlya-razrabotchikov\/",
            "title": "CMS для разработчиков",
            "content_html": "<p>В прошлой своей заметке я обещал, что отдельно остановлюсь о выборе CMS системы с точки зрения разаботчика. Эта тема очень объемна и сегодня я хочу поговорить о подходах к выбору инструментов разработки. Разработчиком я буду называть человека или группу людей, которые «на входе» получают ТЗ, а «на выход» отдают сайт. Далеко не всегда это программисты. Об этом далее.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/koreysha.ru\/pictures\/hudozhestvennaya_obrabotka_metalla_1.jpg\" width=\"897\" height=\"504\" alt=\"\" \/>\n<\/div>\n<p>Я вижу два принципиально разных подхода к выбору инструментов разработки, в том числе, CMS системы. Каждый подход хорош для одних проектов и плох для других.<\/p>\n<h2>Ищем инструмент под задачу<\/h2>\n<p>Суть этого подхода, думаю, понятна из названия. У нас есть задача, формализованная в ТЗ, и мы ищем тот инструмент, который позволит выполнить именно эту задачу, затратив минимум усилий. Именно этот подход я использовал, когда выбрал <a href=\"http:\/\/blogengine.ru\/\">Эгею<\/a> для своего блога.<\/p>\n<p>Подход очень хорош, когда задача  простая или часто возникает у разных людей или компаний с не значительнми изменениями. В этих случаях, как правило, существует инструмент, или даже несколько на выбор, который позволяет эту задачу решить. Для ведения блога таких инструментов очень много и можно выбрать тот, который требует наименьшее количество усилий для «идеальной», с точки зрения заказчика реализации.<\/p>\n<p>Часто этот подход выбирают исходя из команды разработчиков. Например, для того что бы завести блог на <a href=\"http:\/\/blogengine.ru\/\">Эгее<\/a> не нужно быть программистом. Для того, что бы развернуть <a href=\"https:\/\/ru.wordpress.com\/\">WordPress<\/a>, выбрать тему и прикрутить пару плагинов достаточно посвятить изучению этого процесса неделю, но нет необходимости 5 лет учится на мехмате, а потом 10 лет работать в закрытом НИИ. Для того, что бы сделать презентационный одностраничник на <a href=\"http:\/\/tilda.cc\/ru\/\">Тильде<\/a> не надо учить С++ за 21 день.<\/p>\n<p>Если что-то из этого списка и есть ваша задача, то, скорее всего, вам не нужны программисты. Человек, который собирает сайт из готовых модулей — вебмастер. Человек, который сможет помочь вам решить бизнес-задачу переложив её в ТЗ для сайта — дизайнер. Человек, который сможет сделать для вас классные тексты — копирайтер, а, если с помощью текстов он поможет решить вашу бизнес-задачу, то редактор.<\/p>\n<p>Все эти люди могут быть сплоченной командой профессионалов или все эти роли может играть сам заказчик. В этом подходе, скорее всего, вам нужны будут они но не программисты.<\/p>\n<p>С этим подходом, правда очень легко попасть в ловушку. Например, согласно <a href=\"http:\/\/www.rg.ru\/2015\/09\/22\/magaziny.html\">Российской бизнес-газете<\/a> в год в рунете открываются несколько тысяч интернет-магазинов. Отсюда можно сделать вывод, что задача создания интернет-магазина типовая, а значит к ней хорошо применим ход рассуждений  «Ищем инструмент под задачу». Такой вывод — огромная ошибка, которую допускают постоянно. Это связано с тем, что в отличае от блога, сценариев взаимодействия авторов и читателей с котором не так уж и много, в интернет-магазине таких сценариев тысячи, хоть так и не кажется на первый взгляд. Я участвовал в разработке около 20 интернет-магазинов (насчитал сейчас 16, но мог что-то упустить. Честно говоря, далеко не везде я был «на главных ролях», так что может кто-то скажет, что и лишку посчитал) и ни разу логика расчета цен не повторилась точь-в-точь. Даже в очень похожих друг на друга по ассортименту и бизнес-модели магазинах находилась разница. А это всего один из десятков или сотен компонент.<\/p>\n<p>Возможно, все это не относится к маленьким интернет-магазинам, где количество товаров такого, что можно хоть каждый день вручную одному человеку менять их цену, описание и прочие моменты, а так же просматривать в вебвизоре каждого клиента. Так получилось, что у меня таких проектов не было.<\/p>\n<h2>Инструменты для удобства разработки<\/h2>\n<p>При таком подходе, инструменты разработки выбираются так, чтобы упростить жизнь разработчикам, а значит удешевить написание любой логики. Как бы мы не удешевляли, но любая работа должна оплачиваться, а значит разработка точно того же самого, что и в предыдущем подходе все равно будет стоит денег, т.к. полностью готовой логики на момент начала работ нет.<\/p>\n<p>Эта мысль настолько важна, для понимания разницы между подходами, что я переформулирую её еще раз. Разработка при таком подходе стоит дешевле, но при этом нет заранее готовых компонент. Это значит, что все, что можно было бы этими компонентами собрать будет оплачено заказчиком, в отличие от первого подхода. Но, зато все, что «сверху» готового материала, будет стоит дешевле и разрабатываться быстрее.<\/p>\n<p>Понятно, что если проект изначально очень большой, сложный и вообще единственный-в-мире-такой-стартап, то этот подход экономически более оправдан. Но что делать, если я, как заказчик, понятия не имею о том «сложный» мой проект или его может собрать из готовых компонент веб-мастер без существенных доработок? К сожалению, мне известен только один способ ответить на этот вопрос достоверно — консультация с опытными и честными разработчиками.<\/p>\n<h2>Третий подход?<\/h2>\n<p>Широко пропагандируется и третий подход, в котором и овцы сыты и волки целы. Идея заключается в том, что бы уберечь разработчиков от рутинных задач, при этом предоставив им возможность любых доработок в удобной для них среде. Такой вариант дает нам возможность выбирать — вот этот и этот функционал берем «из коробки», а этот и этот пишем с нуля.  Это — утопия.<\/p>\n<p>Чем больше готовых компонент, тем меньше возможностей для их изменения. Это «закон природы», от которого не убежать. Понятно, что можно достичь некоторого равновесия, например 30% первого подхода и 70% второго. Проблема в том, что это только откладывает выбор того или иного подхода. Это временное перемирие, но не завершение войны.<\/p>\n<p>Я не против такого микса, но только в том случае, если все участники процесса четко понимают, что для одних компонент выбран подход «Ищем инструмент под задачу», а для других «Инструменты для удобства разработки» и нет никакого третьего варианта.<\/p>\n<h2>Итог<\/h2>\n<p>Выбор CMS для первого подхода — задача рутинная. А вот для второго и для синтетического варианта — не тривиальная. Я постараюсь высказать свои мысли о её решении в одной из следующих заметок.<\/p>\n",
            "date_published": "2015-12-10T21:52:28+05:00",
            "date_modified": "2015-12-10T21:51:54+05:00",
            "image": "https:\/\/koreysha.ru\/pictures\/hudozhestvennaya_obrabotka_metalla_1.jpg",
            "_date_published_rfc2822": "Thu, 10 Dec 2015 21:52:28 +0500",
            "_rss_guid_is_permalink": "true",
            "_rss_guid": "https:\/\/koreysha.ru\/?go=all\/cms-dlya-razrabotchikov\/",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/koreysha.ru\/pictures\/hudozhestvennaya_obrabotka_metalla_1.jpg"
                ]
            }
        }
    ],
    "_e2_version": 3335,
    "_e2_ua_string": "E2 (v3335; Aegea)"
}