Русский
Русский
English
Статистика
Реклама

Системный анализ

Как работают и отдыхают ИТ-специалисты в пост-карантин?

09.09.2020 10:06:55 | Автор: admin
В марте из-за пандемии COVID-19 Русфинанс Банк (РФБ) и целый ряд других компаний перешли на дистанционный режим работы. После снятия ограничений многие организации возвращаются к работе в офисе, однако РФБ и его ИТ-подразделение продолжает работать удалённо (подробнее о переходе на удалёнку можно прочитать тут).

Мы решили выяснить, как изменилась работа сотрудников после перехода в home office, и заодно познакомить вас с нашими ИТ-экспертами системными аналитиками, бизнес-аналитиками, разработчиками, тестировщиками.

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

Первым нашим собеседником стал Андрей Фетисов, начальник отдела разработки систем взаимодействия с партнёрами (команда, отвечающая за сервисную прослойку между банком и внешним миром в части автокредитования), в прошлом системный аналитик и руководитель группы. Андрей серьёзный руководитель, но в свободное от работы время по-прежнему любит, среди прочего, поиграть в компьютерные игры или заняться написанием музыки.



Чем ты занимаешься в Русфинанс Банке? За что отвечаешь?

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

До этого работал системным аналитиком, затем руководителем группы.

Опиши, пожалуйста, одним словом/ фразой (метафорой, эпитетом), твой девиз в работе.

Поспешишь людей насмешишь.

Какие гаджеты (компьютеры, планшеты, смартфоны) ты используешь в работе/ для личного пользования? Изменились ли они с переходом на удалёнку?

Рабочий ноутбук + домашний компьютер + смартфон + умные часы. С уходом на удалёнку ничего не поменялось. У меня смартфон Huawei Honor 8, исторически пользуюсь Androidом.

Какие операционные системы тебе нравится использовать вне работы? С какими OS было бы интересно познакомиться для себя? Почему интересны именно они?

Использую Windows 10, на *nix никогда не планировал переходить, так как иногда играю в игры, а в те времена, когда я начинал (~20 лет назад), было немало проблем с совместимостью, поэтому так и остался на Windows. И хотя сейчас хобби уже практически сошло на нет, так как перестало затягивать и цеплять, инерция сохранилась.

Изредка собираемся с друзьями на сессионные игры (аналоги настольных игр типа Armello или MOBA типа Heroes of the Storm). Из однопользовательских игр последними меня зацепили Persona 5, Cuphead, Disco Elysium и Horizon: Zero Dawn.

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

В целом для домашнего пользования мне достаточно Windows.
Скучаю по привычному Windows XP

Каким таск-менеджером/ таск-трекером ты пользуешься для работы/ для себя? Почему выбрал именно их?

У меня личного таск-менеджера как такового нет, рабочие дела записываю в физические/ электронные блокноты. Некоторые свои нерабочие дела веду в Google Keep отдельными заметками с перечнем планируемых действий.

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

В рабочем процессе используем Jira. По завершении процесса Discovery (бизнес-анализ, исследование актуальности и окупаемости той или иной фичи) задача заводится в бэклоге Delivery (системный анализ, разработка, тестирование, внедрение). Задачу декомпозируем на подзадачи, берём в работу, включаем в нужный релиз. У типовой задачи будет движение между аналитиком, Oracle-разработчиком, Java-разработчиком, тестировщиком и менеджером приложения (роль, которая в том числе отвечает за внедрение).

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

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

Confluence мы преимущественно используем как базу знаний. Пока вопрос лицензий ещё не решён окончательно. Тем не менее, мы очень надеемся, что сможем собрать в единое удобное для чтения и редактирования место все знания, разбросанные по инструкциям, письмам, головам и так далее. Амбициозно рассчитываю стать одним из основателей процесса управления знаниями в компании (улыбается). Пока мы наполняем базу не слишком активно, так как контрибьютить могут не все участники команды.

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

Сам разработкой не занимаюсь, с кодом работаю в основном в рамках чтения, написания проверочных скриптов. Для этих небольших нужд использую Pl/Sql developer.

Моделированием мы занимаемся не слишком часто, но когда необходимость возникает, использую Visio и Visio-совместимые приложения (например, draw.io).

Какое место в твоей жизни занимает тайм-менеджмент? Какие инструменты/ методики ты используешь для управления своим временем (если есть)?

За время карьеры делал несколько подходов к изучению и применению на практике различных методологий. Честно говоря, по моему мнению, для эффективного менеджмента рабочего времени необходимо, чтобы ежедневно у тебя было сколько-то этого самого времени для планирования (улыбается).

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

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

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

Слушаешь ли ты что-то во время работы/ в перерывах между работой (музыку, аудиокниги и т.д.)? Была ли у тебя такая возможность/ желание до перехода на удалёнку?

В офисе (в open space) постоянно приходилось ставить музыку фоном, чтобы не отвлекаться и сосредоточиться на работе. На удалёнке наоборот: в основном пользуюсь возможностью спокойно сосредоточиться в полной тишине, музыку включаю только под настроение, для творческих задач, вроде ответов на вопросы данного интервью (улыбается).

Какую профессиональную литературу ты читаешь? Что можешь порекомендовать?

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

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

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

Какие полезные профессиональные привычки помогают тебе в работе?

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

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

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

Какой важный совет, который ты когда-либо получал, можешь передать начинающим специалистам в твоей профессиональной области?

Если брать системный анализ, я бы сформулировал два:

1. Всегда старайтесь узнать чуть больше, как в технической, так и бизнесовой части.

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

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

2. Не бойтесь задавать глупые вопросы.

На работе нет места гордости. На 1 из 10* глупых вопросов вы получите не тот ответ, который кажется очевидным.

*Статистика собрана эмпирическим путём

В целом важные на мой взгляд советы:

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

2. Совет, который мне давали мои руководители ещё в самом начале работы в РФБ, когда я был специалистом, а не менеджером. Тогда я к нему не прислушался, потому что он внутренне показался мне неверным. Я смог по-настоящему его оценить только на дистанции. Хотя обоих советовавших я безмерно уважал и уважаю. И в целом всегда старался следовать всем их рекомендациям.

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

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

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

Баги не самый удачный пример, конечно, но, тем не менее, немалое количество вопросов рассасываются самостоятельно в течение часа-двух по тем или иным причинам.

О самоизоляции


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

Дневник Производства 2.0 стартап в стартапе

16.11.2020 20:18:08 | Автор: admin
Что сложнее: запустить стартап-проект в чистом поле или встроить его в готовый продукт? На самом деле одинаково сложно все.

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

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

Хочу рассказать о том, как проходит запуск нового направления МоегоСклада Производство 2.0. С точки зрения бизнеса тема очень любопытна и интересна. Рассказываю в прямом эфире. Эта статья мой взгляд на результаты первых двух недель работы, поэтому смогу погрузить в костер событий и не упущу ни одной шутки.



Краткое содержание:

  • Мы
  • Откуда берутся бизнес-требования
  • Проектируем, предсказывая будущее
  • Производство гробов и модель данных
  • Как не сломить найти общий язык с бизнес-аналитиком, если ты архитектор
  • Мы проработали, но нет. Автомобиль и рыба. Что общего?

Компания МойСклад более 13 лет развивает и продает веб-сервис, упрощающий жизнь малому и среднему бизнесу. Сервис помогает вести складской учет, управлять продажами и закупками, печатать необходимые для ведения бизнеса документы и много-много всего. У нас налажен и постоянно развивается процесс разработки. Сделанные в первый день работы тикеты (на общепринятом языке задачи) могут уже завтра быть на проде. Продукт большой и сложный, пользователи активно делятся пожеланиями. Мы придумываем, как сделать полезный для людей сервис и делаем. И сейчас обновляем блок производства! Мы команда Производство.

Действующие лица первого этапа:

  • Аскар генеральный директор
  • Олег технический директор
  • Максим product owner, направляющий нас
  • Тимур бизнес-аналитик, который знает процессы производства
  • Максим тимлид команды разработки
  • Я системный аналитик

Вводная


Перескажу кратко вводную, которую в первый день спринта, 22 октября 2020-го, мы услышали от Аскара.

Производство в МоемСкладе есть уже давно и у него есть пользователи. Но оно сделано в минимальном исполнении. Можно создавать технологические карты и на их основе либо резервировать товары на складе под производство, либо одномоментно списывать товары и производить готовую продукцию. Это все.



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

В феврале 2020 года в МойСклад написал Тимур (теперь уже наш бизнес-аналитик), работавший тогда с учетом на реальном производстве, с описанием как должно быть, прототипом и предложением о сотрудничестве. В итоге Аскаром принял решение подойти к развитию этого направления основательно и запустить Производство 2.0 обновленное и умное.

Займемся производством




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

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

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

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

Что помогло сделать первый шаг?


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

Рекомендация: перед проектированием системы изнутри, нарисуйте макеты пользовательского UI в любом виде, хоть карандашом на A4. Да, они 100 раз поменяются, и вообще нормальный UI/UX дизайнер потом все исправит, но они должны появиться, чтобы помочь.

На ней все держится. Модель данных


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

Если этот шаг не сделать на старте проекта, то есть шансы в какой-то момент открыть Америку или переделать все. Модель данных это что-то элементарнее фундамента, это Земля, а на ней держится вообще все.

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

В целом обсуждение было построено примерно так:

  1. Для очередной сущности я спрашиваю: Что это такое? и Что мы с этим можем сделать?.
  2. Тимур рассказывает нам о связанных процессах, показывает макеты, приводит примеры.
  3. Все задают много-много вопросов: А можно так?, А что, если...?, удивляются, и иногда кричат Так нельзя!.
  4. Тимур убеждает, что можно и очень надо.
  5. От примера про сборку шкафа мы переходим к примеру про гробы (А если мы производим гробы из австралийского дуба, и нам заказывают модификацию из сосны...).
  6. Смеемся, приходим к компромиссу, дорисовываем в модели данных связанные сущности, описываем ключевые параметры, оставляем заметки уточнить позже.
  7. Фиксируем в статье Вопросы и ответы решения по бизнес-требованиям и ограничениям, если они появились в процессе обсуждения или наоборот, если были сняты.

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



Рекомендация номер два. Если стартап запускается с нуля, то простор для творчества есть и можно брать любых опытных разработчиков с рынка труда. При создании стартапа в готовом продукте, команда должна хотя бы базово знать его, уметь исследовать и не бояться этого. Не запускайте на ранних этапах внутренние проекты с новыми людьми это может быть опасно для существующего продукта. Мы с Максимом ранее работали в других командах МоегоСклада. Для Максима роль тимлида это рост внутри компании. Мое назначение в МоемСкладе: исследовать все и везде. Поэтому вопросов у нас к Тимуру было много. Чем больше вопросов, тем больше ответов. Чем больше ответов, тем больше шансов получить более надежное решение.

Убей в себе архитектора и научись слышать


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

Что разработчики хотят от бизнеса на ранних этапах? Уверенности! Мы много раз разбивали уверенность Тимура о скалы и уводили его от задуманных бизнес-требований к попыткам сделать из того, что есть, или сделать проще. Так нельзя!

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

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



Рекомендация номер три: разработчики от бизнеса ждут уверенности. Если вы бизнес-аналитик и представляете бизнес, или же вы бизнес-заказчик, будьте тверды в своих решениях до последнего, что бы разработчики не говорили. Проще не значит правильно! Если сделать проще сегодня, то завтра доработки выльются в очень большие суммы. Лучше потратить чуть больше в начале и вылить на своего разработчика всю душу (пожелания), чем потом страдать. Разработчик должен знать о потенциальном будущем!

Не откладывай на завтра. НИКОГДА!


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

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

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

Если бы я не писала, а говорила, то это звучало бы как (читать с выражением): М Ну Как бы сказать Короче Вот Каждый третий.

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



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

В завершении первого спринта мы пришли-таки к окончательному решению, и уже совсем скоро наша модель данных позволит детально проектировать и начинать разработку. Макеты детализируются, подключаем коллег по тестированию и UI/UX. Продолжаем творить!

Итого


Чтобы успешно и быстро начать стартап-проект:

  1. Изучите весь известный бэклог, чтобы знать будущее.
  2. Выберите фундаментальную задачу, которая делает/меняет все.
  3. Для внутреннего стартапа нужно подключать команду с опытом решения других задач в развитии продукта.
  4. Слушайте бизнес и дайте вашему бизнес-аналитику эликсир уверенности. Бизнес-требования важнее системных ограничений. Системные ограничения всегда можно преодолеть (это точно)!
  5. Прежде чем что-либо проектировать, посмотрите на систему глазами пользователей нужны черновые макеты UI, которые обязательно будут изменены.
  6. Проектирование нужно начинать с модели данных
  7. Если есть возможность проверить теорию, проверяйте сразу, не откладывая до последнего.

О производстве в МоемСкладе
Подробнее..

Как корова помогла сделать интереснее процесс проектирования

24.11.2020 22:21:52 | Автор: admin
Всем привет! Я ведущий системный аналитик в компании МойСклад и сейчас мы с командой Производство запускаем внутренний стартап внутри стартапа Производство 2.0. Недавно я написала о том, с чего начать процесс разработки в новоиспеченном проекте, а сейчас хочу продолжить рассказ из горящего танка.

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

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



Нужно было переосмыслить бизнес-процессы, чтобы внести уточнения в модель данных и прототипы UI. Примеры про разборку рыбы и автомобиля мы применяли достаточно часто, но эмоционального фона диалогам они особо не придавали. Да и с учетом уточняющихся на ходу бизнес-требований команда устает уже после первого часа обсуждений. Нас пока мало от 4 до 6 человек на онлайн-встречах. Важно держать внимание, чтобы каждый участник был максимально вовлечен в процесс проектирования: разработчик и системный аналитик оценивают реализуемость, тестировщик помогает найти подводные камни, бизнес-аналитик и владельцы продукта помогают разбирать бизнес. Всеобщая концентрация может даваться тяжело, особенно, если транслирует экран и дорисовывает модели / дописывает требования только один человек.

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

Немного определений


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

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

Ресурс товар, из которого производят продукцию.

Техкарта определяет процесс производства группы продукции и является шаблоном в части определения необходимых ресурсов.

Техпроцесс производства упорядоченная последовательность этапов, в результате выполнения которых производится продукция и затрачиваются ресурсы.

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

Техкарта коровы


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

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

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



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



Это простые техкарты, которые поддерживает текущее производство МоегоСклада. А теперь усложним.

Вариант 3: У меня есть мясной цех, упаковочный цех и луг. Я забираю 10 коров с луга. Сначала я превращаю 10 коров в очень много частей этап разборки, затем сортирую полученные части этап сортировки, а после помещаю в упаковки. Это все делается по сложной техкарте разборки коровы. Полученная техкарта:

Ресурсы: 1 корова, 100 м2 вакуумной упаковки.
Готовая продукция: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка

Производственный процесс:

  1. Этап разборки (Ресурсы: 1 корова)
  2. Этап сортировки (Ресурсы: нет новых ресурсов, используются результаты этапа разборки)
  3. Этап упаковки (Ресурсы: 100 м2 вакуумной упаковки)

Получается, что я могу взять с луга как одну корову, так и 10, и 20 и т.д. И этот прекрасный вопрос бизнес-аналитику: Тимур, а можно произвести 1,5 коровы?. Истерика. Ответ: Можно. Мы же не только с коровами работаем, ограничения не ставим. Захотят пол коровы, возьмут половинку с луга или из морозильника.



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

Да, 1,5 коровы тоже допускаем.

Полученная техкарта:

Ресурсы: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка, серебро.
Готовая продукция: 1 корова, 1 колокольчик.

Производственный процесс:

  1. Этап сборки (Ресурсы: 1 упакованная лопатка, 1 упакованная печень, упаковка на 2 стейка)
  2. Этап реанимации (Ресурсы: нет новых ресурсов, используются результаты этапа сборки)
  3. Этап производства колокольчика, может идти параллельно этапу реанимации (Ресурсы: серебро)
  4. Этап надевания колокольчика на корову (Ресурсы: нет новых ресурсов, используются результаты предыдущих этапов)



Такая модель помогла нам доопределить бизнес-правила и ограничения:

  • Можно ли в простой техкарте сборки установить норму готовой продукции 1?
  • Могут ли быть готовые продукты по результатам промежуточных этапов?
  • Можно ли задавать не целые нормы?

И много-много других.

И конечно, мы окончательно определились с кусочком монстра модели данных.

Техоперация и производственный процесс


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

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

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

Утверждения, вопросы и ответы:

Утверждение от бизнеса. Вы, как производитель, можете отслеживать процесс производства коровы поэтапно.

Вопрос. Могу ли я просто зарегистрировать, что было производство коровы, без контроля по этапам?

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

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

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

Вопрос. А можно ли в заказе на производство донастроить техкарту так, чтобы в нем была только нога?

Ответ. Нет, тогда нужно создавать новую отдельную техкарту. Пример Техкарта Лопатки коровы

Вопрос. А можно ли в заказе на производство донастроить ресурсы из техкарты, увеличив количество коровы с 1 до 1,2 и добавить до ресурсы?

Ответ. Да, можно, потому что может быть брак, может приехать корова побольше и т.д.
И так далее.

Не для слабонервных

У меня была корова и я начал отпиливать от нее две ноги.





По итогам обсуждений были введены новые термины и определения в производстве мясной продукции:

  • Кортеж готовой продукции (коровы) неизменяемая группа готовой продукции, указанная в качестве результата производства по техкарте.
  • Сборка (коровы) процесс производства, в результате которого получается одна готовая продукция при любом количестве ресурсов.
  • Разборка (коровы) процесс производства, в результате которого получается более одной готовой продукции при любом количестве ресурсов.
  • Техоперация (над коровой) мгновенное производство в один этап.
  • Техпроцесс производства (коровы) поэтапное производство (приготовление) коровы
  • Проблематика коровы

В заключении


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

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

Во-первых, это весело.

Во-вторых, это заставляет фантазию работать более креативно и извлекать из головы правильные вопросы.

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

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

Маленькими шагами к красивым решениям

16.05.2021 12:20:18 | Автор: admin

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

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

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

Снаружи для пользователя, внутри для команды разработки

Архитектура системы определяет скорость ее развития. Красивая и правильная архитектура вдохновляет работать и помогает команде разработки.

Вдохновляет простое. К простым и красивым решениям не всегда возможно прийти с первого раза. Ошибка тоже результат.

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

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

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

Модель

Объектная модель должна быть понятна не только разработчикам, но и пользователям.

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

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

Логика

Упрощайте алгоритмы. Делите сложные части на простые. Не переусердствуйте.

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

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

Алгоритм должен легко читаться: в тексте, в любой нотации моделирования, в коде.

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

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

Нейминг решает

Если назвать бокал стаканом, то назначение "пить" вроде бы не меняется, но что-то все-таки не то.

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

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

Имена объектов и методов в конечном счете становится языком команды разработки, заказчика ПО и даже пользователей.

MVP и прототипы

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

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

Рефакторинг

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

Своевременный рефакторинг ускоряет разработку. Больше времени сегодня на задачу, в рамках которой надо сделать рефакторинг, меньше времени на будущие задачи.

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

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

Документация

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

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

Выводы

Не усложнять.

Ничего не прятать.

Называть все своими именами.

Не стоять на месте.

Не поддаваться отчаянию, если не получилось.

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

Подробнее..

Момент, когда проектная документация нужна

28.12.2020 12:07:24 | Автор: admin
Время идет, планета крутится, системы растут и развиваются, а я продолжаю слышать в кругах аналитиков сожаление: Эх, пришел на проект, а тут никакой документации, смотрим в код.

Но это ерунда. Хуже, когда заказчик говорит: Создали два разработчика. Уволить не могу, хотя почти ничего не делают, только по мелочи донастраивают. А с этой системой у нас уже и бухгалтерия интегрирована, и Документация? Нет ее. А надо?.. Спасите-помогите!

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




Что это за зверь документация?


С чего начинается задача на разработку? С идеи. Чтобы что-то создать, нужно это представить в своей голове. Чтобы не потерять мысль, её лучше зафиксировать.

По сути, документирование это процесс описания идеи от момента ее возникновения в сознании до выпуска результатов в в релиз. А значит документировать мы начинаем в момент написания ТЗ, при описании задачи, без строгого формата, в картинках или на листе бумаги. Когда мы формализуем, как это должно работать.

Для кого документировать?


Если нет понимания, кому нужна проектная документация, то она не нужна. Возможно, прочитав эту статью чуть дальше, мнение может резко поменяться, но это не точно.



В первую очередь документация нужна команде разработки и заказчику.

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

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

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

Иногда проектная документация нужна просто потому, что так сказали.

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

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

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

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

Причины, по которым компании приходят к внедрению документирования


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

Есть сервис МойСклад и 2007 год. Прекрасный пример стартапа от двух разработчиков. Фундамент сервиса был целиком заложен Аскаром (генеральный директор) и Олегом (технических директор). Если почитать историю создания МоегоСклада, то можно узнать интересный факт уже тогда было неосознанное документирование продукта в рабочей тетрадке в клеточку!

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



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

Пример с автомастерской


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

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

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



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

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

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

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

И все успешно получится, потому что система обычная, никаких наворотов нет.



Но вот привезли Aston Martin или Ferrari. А я обычный механик в среднестатистической автомастерской. Конечно, сначала я обрадуюсь такому. Но потом, когда дело дойдет до ремонта, я буду вдумчиво смотреть на это чудо света и искать все возможные инструкции, чтобы устранить неисправность.

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

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

В отсутствии проектной документации основная стоимость разработки будет потрачена на изучение того, как оно работает, что это и почему так.

За 13 лет МойСклад смог очень круто подрасти: веб-приложение для RU- и US-площадок, кассовое ПО для трех платформ, мобильные приложения, шесть протоколов API и много-много всего.

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

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

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

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

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



Программный код и есть документация


Так говорят разработчики. И нет, это не так.

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

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

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

Как нас много


Как масштаб проекта по части количества людей влияет на необходимость появления документации.











Сервис МойСклад начинался с Аскара и Олега 13 лет назад. Целиком знают продукт всего три человека: Аскар, Олег и Максим присоединившийся к ним немногим позже продакт и бизнес-аналитик.

Сегодня компания насчитывает более 150 человек. Три хранителя знаний на тридцать сотрудников? Возможно. А на команду от ста человек? Да и помнить все детали, особенно когда реализовывал их не ты, просто невозможно. Поэтому нормой стал ответ смотри как на проде.

Если каждый новый сотрудник будет начинать уточнять как работает та или иная часть системы при получении новой задачи, то он будет отнимать время у коллег. Изменению подвергаются самые разные части Склада. Не всегда удается установить их истинное поведение, которое задумывалось изначально.
Баг или фича?

Может ответить только зафиксированное знание, которое либо есть, либо нет, либо оно в человеке (а значит его нет).

В МоемСкладе стали важными такие умения, как археология по коду у разработчиков, археология по возможностям системы у тестировщиков и аналитика.

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

Не храните знания в людях это опасно


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

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



Сегодня все более актуальна тема с удаленной работой, да и ранее команды разработки всегда обсуждали задачи в чатах (Slack, Telegram, Skype и т.д.).

В какой-то момент жизни продукта может настать перевес: переписки у разработчиков занимают больше рабочего времени, чем решение задач.

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

Моя позиция такова: стараюсь минимизировать развернутые ответы на вопросы в чатах и максимально ссылаться на существующую документацию:

Разработчик: [Вопрос]
Я: [ссылка на Confluence] п. [название]


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

И про контекст










Итого: где же тот самый момент?


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

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

Что может дать наличие документации на программный продукт?

  • Меньше обсуждений в чатах и поисков причин почему так.
  • Быстрее погружение в контекст.
  • Команде проще понимать и оценивать объем изменений для новых задач.


А такой результат влечет за собой как минимум экономическую выгоду.

Ссылки


analystdays.ru/ru/talk/83497 Analyst Days. Как мы процесс документирования внедряли
habr.com/ru/company/moysklad/blog/452016 Сервис МойСклад 12 лет в облаке (уже 13!)
Подробнее..

Аналитик в автоматизации кто он и чем занимается

19.05.2021 22:12:58 | Автор: admin

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

Как главный аналитик в ADV/web-engineering co, я регулярно отвечаю на подобные вопросы коллег и соискателей на собеседованиях. Надеюсь, что эта статья поможет сформировать представление о возможном развитии и ожидания от работы аналитиком в той или иной компании.

Какие бывают аналитики

Наглядный профит от использования аналитикиНаглядный профит от использования аналитики

Если поискать в интернете, то найдётся куча видов таких млекопитающих:

  • Аналитик (вот так, просто аналитик)

  • Аналитик БД

  • Аналитик бизнес-процессов

  • Бизнес-аналитик

  • Системный аналитик

  • UX-аналитик

  • Продуктовый аналитик

  • Аналитик данных

  • BI-аналитик

  • Веб-аналитик

  • Технический писатель

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

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

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

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

Специалисты широкого спектра

Сюда отношу тех, кто как правило задействован в автоматизациях, например, в интеграторах или в разработке продукта в in house команде. Такие люди чаще решают следующие задачи:

  • Сбор требований с руководителя продукта

  • Формирование предложений по развитию продукта

  • Проектирование бизнес-процессов

  • Постановка задач дизайнерам

  • Подготовка спецификаций для разработчиков

  • Сопровождение разработки и тестирования

  • Верификация разработки, то есть проверка того, что разработка сделала всё так, как и задумывал аналитик

  • Взаимодействие со специалистами узкого спектра, о них позже

  • Участие в presale и предпроектных активностях

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

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

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

Что пригодится такому аналитику

Простая формула идеального аналитикаПростая формула идеального аналитика

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

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

  • Бизнес-анализ 30%

  • Системный анализ 35%

  • Продуктовый анализ 15%

  • UX-аналитика и дизайн 10%

  • Менеджмент 5%

  • Прочее последние 5%

Если детальнее, то из бизнес-анализа стоит знать:

  • Бизнес-процессы --- зачем они нужны, зачем их формализуют

  • Нотации моделирования бизнес-процессов, базовые знания BPMN необходимы

  • Логику и правила проектирования логической модели данных

  • Правила сбора требований и ограничений

  • Отдельно отмечу правила сбора требований к пользовательским интерфейсам

Для системного анализа пригодятся:

  • Типовые архитектурные паттерны

  • Навыки программирования алгоритмы, типы данных, наследование

  • Знания БД, понимание концепций нормализации и денормализации, реляционных и нереляционных СУБД

  • Представление о нотациях UML, умение работать с базовыми диаграммами (диаграмма последовательности, вариантов использования)

  • Понимание концепции декомпозиции задач на конкретные работы, хотя бы банально на back и front

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

  • Понимание работы тестирования и умение самому представлять возможные не-happy path варианты работы решения

Для решения задач продуктового анализа потребуется:

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

  • Базовое понимание метрик и их ценностей для продукта

  • Умение расставлять приоритеты между задачами и понимание концепции MVP

Для корректного взаимодействия с дизайнерами необходимы базовые знания UX/UI:

  • Сложно формализуемое чувство прекрасного для интерфейса и умение поставить себя на место пользователя

  • Понимание компонентного подхода при проектировании интерфейсов

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

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

Про узких специалистов

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

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

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

  • Нравится копаться в системных штуках системный аналитик, и там до архитектора

  • Любишь работать с данными аналитик БД, BI или в сторону data science

  • Интересно продумывать пользовательский путь и управлять им UX-аналитик, UX/UI-дизайнер

  • Горишь в том, чтобы принимать решения и развивать продукт продуктовый аналитик, и далее до руководителя продукта

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

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

Итоги

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

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

Подробнее..

Из песочницы Обновленный браузер Safari как быть маркетологам

20.09.2020 02:20:07 | Автор: admin

Что произошло?


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


  • Google Tag Manager
  • Google Analytics
  • Facebook
  • Яндекс.Метрика
  • Mail.ru (myTarget)
  • Doubleclick (Floodlight)
  • VK

Вот так это выглядит:


image


Статистику по заблокированным пикселям можно также отследить в Safari:


image


И в iPhone и iPad:


image


Что происходит, если серфить интернет с помощью обновленного браузера Safari:


  • ни одна стандартная система веб-аналитики, а значит и бренды, не могут отследить действия пользователя;
  • пользователь не попадает в ремаркетинговые аудитории;
  • не работает Google Tag Manager.

Важно понимать

Соблюдение конфиденциальности пользователей и усиленная защита данных сейчас популярный рыночный тренд. Это понимают компании-разработчики браузеров, постепенно внедряя технологии повышенной приватности. Для справки: доля пользователей браузера Safari на рынке составляет 17%. И хотя ограничения в будущем только усилятся, мы еще можем успеть подготовиться и улучшить работу наших систем аналитики.


Как ограничение работает на самом деле?


Многие тематические ресурсы и обозреватели (такие, как Apple Insider и Search Engine Journal) не совсем корректно поняли сообщениями в браузере Safari и вышли с громким сообщением, что трекинг-системы перестали работать. На самом деле обновленная версия браузера не блокирует работу трекинговых систем, а повышает конфиденциальность даннх пользователей и показывает пользователю сообщение о том, какие трекинг-системы обнаружены на веб-сайте.


Как решить проблему?


Весной в Google Tag Manager появилась бета-версия функции настройки отслеживания на стороне сервера (Server-side Tagging).


image


Как работает Server-side Tagging


Если вкратце, то тегирование на стороне сервера позволяет запускать контейнеры Google Tag Manager на серверном окружении. К сожалению, на данный момент инструмент все еще находится в стадии бета-тестирования, поэтому пока что доступен только вариант установки на серверах Google Cloud Platform, однако будем надеяться, что поддержка других серверов появится в ближайшее время.


Отличия от стандартных контейнеров


Во многом тегирование на стороне сервера похоже на стандартные контейнеры Google Tag Manager:


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

Однако, есть и отличия:


  • контейнер серверного типа отличается от web-, app- и AMP-контейнеров;
  • триггеры срабатывают не при наступлении событий на сайте, а при получении входящих HTTP-запросов;
  • эти HTTP-запросы обрабатываются Клиентом это новая сущность GTM, которая является адаптером между устройством пользователя и серверным контейнером;
  • клиент обрабатывает запросы, генерирует объект данных события и выгружает его в виртуальный контейнер, с помощью которого теги могут обращаться к объектам событий, чтобы отправлять данные в сторонние системы.

Вот схема работы нового типа контейнеров:


image


А вот как выглядит интерфейс отличий от стандартного веб-контейнера совсем немного:


image


Более подробно про добавление тегов на стороне сервера можно прочитать в официальной документации.


Преимущества Server-side Tagging


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


Скорость загрузки сайта


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


Все данные хранятся у вас


Вы полностью контролируете и владеете всеми данными на сервере Google Cloud:


  • сервера Google Cloud обрабатывают только те данные, которые вы хотите обрабатывать;
  • вы владеете всеми данными. Google не использует ваши данные для рекламных целей;
  • вы всегда знаете и контролируете в каком регионе хранятся ваши данные;
  • хранение данных производится со всеми современными стандартами безопасности.

Обходим блокировки трекеров отслеживания


Блокировка трекеров и пикселей обычно осуществляется двумя способами:


  • блокируется JS-код от трекеров (пиксели на сайте);
  • блокируется домен трекера, чтобы предотвратить отправку данных на него.

С помощью серверного отслеживания мы обходим обе эти проблемы:


  • мы переносим логику из пикселей на серверное окружение, не размещая на сайте JS-код, поэтому браузер не сможет его заблокировать;
  • мы можем привязать к серверному контейнеру свой домен, поэтому блокировка по домену не будет работать.

Недостатки серверного отслеживания


Дополнительные расходы на сервер в облаке


На данный момент GTM поддерживает размещение серверных контейнеров только на серверах Google Cloud. Стоимость аренды одного сервера начинается от 40 долларов в месяц.


Не все пиксели можно поставить через серверный контейнер


Серверный контейнер работает как замена JS-коду на стороне браузера, поэтому поставщик пикселя должен уметь принимать данные через HTTP-запросы.


Для простого отслеживания, как правило это не является проблемой. Но проблемы могут возникнуть, если в скрипте используется сложный JS-код, который нельзя перенести на сервер, как например в Вебвизоре от Яндекс.Метрики. Он точно не будет работать.


Как внедрить отслеживание на стороне сервера?


  1. Создать серверный контейнер в Google Tag Manager;
  2. Зарегистрироваться на Google Cloud Platform, создать новый проект и настроить способ оплаты;
  3. Развернуть сервер Google Cloud AppEngine;
  4. Привязать свой домен к созданному серверу;
  5. Перенести теги, триггеры и переменные из веб-контейнера в серверный контейнер GTM.

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

Подробнее..

Техдолг нельзя копить, закрывать

05.05.2021 14:10:44 | Автор: admin

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

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

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

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

В этот момент вы вспоминаете: Почему я не выполнил сразу работы по ремонту, а отложил их подальше?!

Вот и с техдолгом похожая ситуация.

Какими могут быть последствия накопления техдолга?

  • Снежный ком документов

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

  • Отсутствие экспертизы для будущих поколений

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

  • Время разбора дефектов увеличивается

Наташ, мы все уронили!

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

  • Негатив от команды

Разработчики пишут код со слов, тестирование тестирует со слов, а бизнес думал, что его слова по-другому поняли. В итоге функционал работает, но когда начинаешь разбираться, как работает, появляется много вопросов, и нет документации, где посмотреть

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

Что мы сделали?

  1. Собрали рабочую группу, в которую включили аналитиков от каждого направления из центра компетенций аналитики удаленных каналов доступа (Альфа-Мобайл, Сайт, Интернет-банк и др);

  2. Определили, что такое техдолг, и как выбирать приоритеты;

  3. Расписали процесс ведения, включения задач по техдолгу в бэклог, ответственных;

  4. Сформулировали ситуации, сигнализирующие, что техдолг растет, и определили, что делать в таких случаях;

  5. Собрали задачи по техдолгу в рамках направлений.

Что такое техдолг и как выбирать приоритеты?

Отсутствующей документации (техдолга) может быть много, поэтому важно правильно выставить приоритет у задач. Мы выбрали основные приоритеты: важный, средний, низкий.

......

Приоритет

Ситуация

важный

На функционал в промышленной среде нет документации;

Нет архитектурной документации, которая блокирует поставку функционала в прод.

средний

Существующий документне соответствует актуальному шаблону. Документ сложно читать и понимать. Приоритет выбирается совместно с техлидом аналитика;

неактуальный; не полностью описывает функционал в проде.

низкий

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

Нет архитектурной документации, которая не блокирует выкат в прод функционала.

Как завести задачу по техдолгу в backlog?

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

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

Правила ведения задач в jira

Поле

Как заполнить

Тип

task

Приоритет

Важный

Средний

Низкий

Метки

Техдолг_команда_функциональность

Тема

[вид функциональности] Описание работ

Вид функциональности: фронт, сервис (имя), архитектура

Описание работ: написать/актуализировать

Описание

Цель: опционально, когда необходимо обосновать приоритет

Что: написать/актуализировать + ссылки на материалы

Dod: аналитика подготовлена, согласована

В качестве инструкции и отчета в первой версии создали статью в Confluence с содержанием:

  • Что такое техдолг

  • Почему важно закрывать техдолг

  • Ответственность

    • Кто добавляет задачи

    • Как задача попадает в техдолг

  • Процесс работы с техдолгом

  • Как ведем задачи в Jira

    • Кто закрывает техдолг

    • Кто следит за выполнением

  • Список задач

    • Срез задач на 2 квартал 2021

Список задач собрали автоматически с помощью макроса Jira и настроили возможность фильтрации с помощью макроса Фильтр таблиц. Для визуального отображение использовали макрос Jira круговая диаграмма

Что делать, если техдолг растет

Ситуация 1 растет тех.долг

Решение: Бери задачи по техдолгу в работу в sprint.

Ситуация 2 увеличилось время разборов дефектов из-за отсутствия документации

Решение: Выполняй задачи по техдолгу.

Ситуация 3 хочешь повысить оценку компетенций для продвижения по карьерной лестнице

Решение: Помогай другим направлениям закрывать их техдолг.

Как закрывать техдолг, а не копить

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

Каждый аналитик из рабочей группы в рамках своего направления:

  • создал задачи в JIRA по текущему техдолгу;

  • написал статью по шаблону. Пример статьи был выше;

  • обсудил с аналитиками из своего направления, кто какие задачи возьмет в работу в следующем квартале;

  • рассказал аналитикам из своего направления, какие правила заведения задач по техдолгу.

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

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

Следующим шагом будет настройка dashboard для мониторинга прироста задач по техдолгу.

Предупрежден значит вооружен.

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

Подробнее..

Как мы унифицировали онбординг аналитиков удалённых каналов доступа

20.11.2020 12:14:59 | Автор: admin
Испытательный срок это не только время, за которое компания проверяет, правильного ли сотрудника взяли на ставку, справляется ли он с обязанностями и как в целом работает. Это в том числе (об этом часто забывают) период, за который сотрудник не менее пристально оценивает компанию: соответствуют ли задачи озвученным на собеседовании, как дела с командой, адекватно ли выстроены рабочие процессы, да и вообще нравится работать тут или нет.

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



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

Зачем вообще унифицировать онбординг


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

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

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

Чего хотелось добиться


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

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

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

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

Результатом виделось вот такое положение дел.

  • с первых дней выхода человека в штат максимально насыщаем его всей нужной информацией
  • при этом помогаем наставникам проводить на самом деле качественный онбординг
  • унифицируем систему оценки качества проведенного онбординга


Как решили всего этого добиться


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

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

Все картинки кликабельны







Во-вторых, было сформулировано 6 критериев для оценки аналитика УКД архитектура, документация, техника, процессы, работа с ошибками и коммуникации. По каждому критерию выделены требования к аналитику и приведены ссылки на справочные материалы.



И наконец, на основе требований к аналитику мы разработали шаблоны планов на испытательный срок (мы их называем планами на 100 дней). Шаблоны были разработаны в привязке к каналам и учитывали как общие требования, так и специфику канала.



Что же в итоге


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

Онбординг стал более полным. Раньше оценка велась преимущественно по трем критериям процессы, архитектура, аналитика (под которой часто понималась документация). Теперь критериев шесть.

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

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

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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru