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

Управление разработкой

Перевод Парное программирование цели, преимущества

08.06.2021 10:08:20 | Автор: admin

Это продолжение перевода статьи о парном программировании. С первой частью можно ознакомиться здесь.

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

Итак, как же работа в паре поможет достичь этих целей?

Обмен знаниями

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

Практические советы

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

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

Размышления

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

Практические советы

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

Сосредоточение

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

Практические советы

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

Ревью кода на ходу

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

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

Но совместное ревью кода имеет также и свои минусы. К ним мы вернемся позже.

Практические советы

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

Совмещение двух моделей мышления

Как мы упоминали ранее (в первой части), рассматривая классическую модель Ведущий/Штурман, совместная работа позволяет получить разные взгляды на код. Мозг Ведущего обычно работает в режиме тактики, размышляет о деталях и текущих строчках кода. В то время как мозг Штурмана думает более стратегически и охватывает бОльшую картину, отмечает следующие шаги и идеи на клеющихся стикерах. Может ли один человек сочетать в себе оба режима одновременно? Конечно, нет! Поэтому такой "удвоенный" взгляд улучшает качество кода, так как включает рассмотрение и деталей, и общей картины.

Практические советы

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

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

Коллективное владение кодом

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

Мартин Фаулер

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

Практические советы

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

Установка WIP-лимитов для команды

Ограничение числа незавершенных задач, как один из базовых принципов Канбан, увеличивает продуктивность сотрудников. Следование технике WIP-лимитов (аббревиатура от Work In Progress) помогает сосредотачиваться на ключевых задачах. Многозадачность неэффективна даже для одного человека, что говорить о целой команде. Парное программирование позволяет ограничить число задач, прорабатываемых параллельно, и тем самым увеличить общую сосредоточенность. Это гарантирует непрерывность рабочего процесса без подводных камней.

Практические советы

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

Быстрая адаптация новых сотрудников

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

Практические советы

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

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

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

Подробнее..

Перевод Про комментарии к коду

16.06.2021 00:20:01 | Автор: admin
image

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

Javadoc самый бесполезный


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

image

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

Самодокументируемый код


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

Когда комментировать


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

image

Еще один пример:

image

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

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

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

Логи как комментарии


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

image

Анализ комментариев


Когда я впервые подумал о том, чтобы проверить, сколько комментариев содержится во всех моих коммитах, я подумал, что будет достаточно одной строки, чтобы найти комментарии во всех моих коммитах Python (я комментирую только с помощью #):

git log --author=Henrik -p|grep '^+[^+]'|grep '#' | wc -l

Однако вскоре я понял, что мне нужны более подробные сведения. Я хотел провести различие между комментариями в конце строки и комментариями всей строки. Я также хотел узнать, сколько блоков комментариев (последовательных строк комментариев) у меня было. Я также решил исключить тестовые файлы из анализа. Кроме того, я хочу обязательно исключить любой закомментированный код, который там оказался (к сожалению, таких случаев было несколько). В конце концов я написал скрипт на python для анализа. Входными данными для скрипта были выходные данные git log --author=Henrik -p.

Из выходных данных я увидел, что 1299 из 17817 добавленных строк моих содержали комментарии. Был 161 комментарий в конце строки и 464 однострочных комментария. Самый длинный блок комментариев составлял 11 строк, и было 96 случаев блоков комментариев, которые имели 3 или более последовательных строк.

Выводы


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

Платформа управления бизнес-процессами практика внедрения

01.06.2021 12:20:22 | Автор: admin

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

Производственные системы и их решения

Об одном из показательных примеров - о совместном решении Dassault Systemes и ГК Цифра - рассказал старший технический специалист компании Dassault Systemes Дмитрий Лопаткин. Группа компаний Цифра разрабатывает и внедряет платформенные решения на основе промышленного искусственного интеллекта и интернета вещей, а также развивает индустрию роботизированного промышленного транспорта.

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

Если говорить о программном продукте для оперативного управления производством компании Dassault Systemes - DELMIA Apriso и его архитектуре, то на его самом нижнем уровне лежит собственная, встроенная платформа управления бизнес-процессами Process Builder. И это единственный обязательный реквизит, необходимый для внедрения подобных систем. Именно здесь описываются все производственные процессы, входящие в контур цифровизации. Помимо самих процессов прописываются все интерфейсы подключения к оборудованию через системы автоматизации или непосредственно подключение бизнес-систем, таких как ERP. На эти бизнес-процессы наслаиваются функциональные модули, которые могут применяться на пользователями из различных производственных дисциплин: контроль качества, склады, ТОиР, декларация производства. Это те элементы, с которыми взаимодействует конечный пользователь оператор ЧПУ, плановик, сотрудники логистической или ремонтной службы и пр.".

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

Описание и моделирование бизнес-процессов

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

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

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

Также можно моделировать, как себя будет вести процесс "в реальной жизни" - ещё до его запуска в производство. С точки зрения конечного пользователя эти изменения не видны, то есть, если в процесс внесены какие-то улучшения или усовершенствования в рамках BPM-платформы, то пользователь не увидит изменений, которые произошли в бизнес-процессах. Такая интеграция и возможность работы с процессами рамках инструмента Process Builder позволяет постоянно улучшать процессы, то есть можно сделать какое-то изменение, чтобы посмотреть, как это выглядит в реальной жизни, получить обратную связь от производства, оценить такие показатели как объем производства, выявить "узкие места" или внести изменения в процесс системы управления производством.

Ядро и интерфейсы пользователя

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

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

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

Масштабирование системы

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

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

Что даёт такой подход с точки зрения информационных технологий? Во-первых, это высокая скорость внедрения. Обычно 60%-70% времени тратится на разработку основного решения (core), а дальнейшее внедрение требует уже незначительного времени. Например, на подключение новой производственной площадки уходит 2-3 недели, что по меркам систем управления производством очень малый срок.

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

Интеграция с "Цифрой"

Например, данный подход использовался для интеграции с решениями компании "Цифра". Изначально это был небольшой процесс, начинающийся с производственного заказа. В данном случае производственный заказ состоит из трех операций. Первая из них выполняется на оборудовании, имеющему свой АРМ.

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

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

Третья операция - операция сборки. У оператора на сборке своя задача и свои потребности: он хочет видеть весь процесс детально. Он проходит обязательный контроль соблюдения мер безопасности. Эта информация в рамках системы контроля качества сохраняется в системе управления производством Apriso. Каждый индивидуальный использованный материал и полуфабрикаты также заносятся в систему управления производством и добавляются в генеалогию изделия.

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

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

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

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

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

Преимущество такого решения в том, что оно позволяет собирать информацию c оборудования компании "Цифра". Есть система контроля процессов. Такой совместный подход дает большую синхронизированность работы всех производственных служб, увеличение эффективности использования оборудования и гибкости производства в целом. Всегда можно оперативно отреагировать на изменения, которые требует ситуация на рынке. Решение DELMIA Apriso обеспечивает глобальное управление процессами, контроль производительности, визуализацию и тщательный анализ влияния функциональных улучшений на всех производственных площадках в рамках предприятия.

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

Заинтересовала данная тематика?

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

Познакомьтесь с материалом "Системы управления производством и производственными операциями и современные вызовы".

Узнайте больше о продуктах DELMIA на официальном сайте компании

Подробнее..

Обновленный плагин YouTrack для IDE на платформе IntelliJ

03.06.2021 20:19:56 | Автор: admin

Привет Хабр!

В командах разработки трекеры задач и IDE редко существуют друг без друга. Поэтому мы решили существенно проапгрейдить плагин YouTrack для IDE на платформе IntelliJ. Плагин интегрируется с вашими любимыми IDE от JetBrains AppCode, CLion, DataGrip, GoLand, IntelliJ IDEA, PhpStorm, PyCharm, Rider, RubyMine и WebStorm, а также с Android Studio и дает вам доступ ко всем задачам и уведомлениям прямо из IDE. Также с помощью плагина стало удобнее вести учет времени. Для него появилось несколько режимов теперь вы сможете сосредоточиться на написании кода и не тратить время на отчетность. Ниже расскажу обо всем подробнее.

Карманный трекер: все под рукой

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

Плагин отображает список задач, актуальных для вас прямо сейчас. Это может быть ваш личный бэклог, задачи к предстоящему релизу, технический долг. Список можно в любой момент изменить, выведя на первый план актуальные задачи. Вы можете обновлять задачи прямо из IDE: добавляйте комментарии, выполняйте команды и меняйте статус все это позволит держать команду в курсе прогресса. Кроме того, плагин позволяет получать в IDE уведомления об изменениях в задачах (те же, что вы получаете по почте) и наоборот создавать новые задачи в YouTrack всего за пару кликов, предварительно выделив нужный кусок кода в IDE.

Остаемся в контексте текущих задач

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

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

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

Теряем счет времени с автоматическим режимом учета

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

У автоматического режима есть несколько настроек. Например, он может вносить в систему затраченное время при каждом коммите, при закрытии проекта в IDE, по заданному вами графику (например, каждый день в 19:00) или по прошествии определенного периода неактивности в IDE.

Контролируем каждый шаг в ручном режиме

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

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

Попробуете?

Лучше один раз увидеть, чем сто раз услышать. Плагин можно использовать с версией 2021.1 всех IDE JetBrains на платформе IntelliJ, включая AppCode, CLion, DataGrip, GoLand, IntelliJ IDEA, PhpStorm, PyCharm, Rider, RubyMine и WebStorm, а также с Android Studio. Чтобы установить плагин, откройте в IDE меню Settings -> Plugins и найдите там плагин YouTrack Integration.

Для настройки плагина вам понадобится YouTrack версии 2020.4.6808 или младше и постоянный токен.

Каких еще возможностей вы ждете от интеграции? Что позволило бы еще эффективнее использовать YouTrack вместе с IDE? Расскажите нам о своем опыте! Ваши отзывы помогут нам сделать плагин YouTrack еще лучше.

Ваша команда YouTrack

Подробнее..

КакстроитьдиаграммуГанттапоJira-тикетам

04.06.2021 08:06:10 | Автор: admin

Время чтения: 5 минут

Статья для менеджеров, которым необходимо вести управление проектами и ставить сроки в изменчивом мире Agile. Поделюсь опытом использования двух приложений Jira Roadmap и Structure Gantt.

Пример Диаграммы Гантта Пример Диаграммы Гантта

Ганттдля(ленивых) экономящих свое время

Для построения диаграммыГантта существует множество программ: Ganttpro, Monday, Teamgantt,старый добрыйExcelи другие.

Нам с коллегами в Ozonони не подходили,потому чтоежедневная работа завязана наJira-тикеты.Чтобы пользоваться сторонними сервисами, приходилосьпереписывать всю информацию изJiraещёраз (название задачи, исполнитель, связи, статус).Этотребовало много времении терпениянамонотонную механическую работу.

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

  1. JiraRoadmap

  2. StructureGantt

JiraRoadmap

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

Jira RoadmapJira Roadmap

О приложенииStructureвOzonбыло известно давно. Однакоононебросалось в глаза,пока не обратили внимание на еговозможность строитьдиаграммуГантта.Рекламное видео отправило всех в менеджерский рай: информация из Jira-тикетовотражается, можно группировать задачи по статусу, связи подсвечиваются, не мешает команднымKanban-доскам.Минимум монотонной механической работы.

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

StructureGanttк функционалуStructureдобавляется возможность видетьJira-тикетыи связи между задачами на временной ленте.

Structure GanttStructure Gantt

В конце 2020 годаруководители Ozon приобрелиStructureGanttдля удобного и наглядного ведения проектов. Однаков менеджерском раю оказаться сразу не получилась.Причины: сложная функциональностьи отсутствиенаглядногообучающего материала.

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

  • В чате Slack#jira-structureможнобылооперативно получить ответ на вопрос по работе приложение или поделиться своими находками.

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

  • Созванивались и пытались коллективным разумом найтивыход из тупиковых ситуаций.

Слабые стороныStructureGantt

Сильные стороныStructureGantt

Сложно разобраться с инструментом

Богатаяфункциональность

Невозможно увидеть время переходаJira-тикетыиз одного статуса в другой

Вся информация автоматически дублируется междуJira-тикетамииStructureGantt

В мануалах нет примеров использованияна практике

На одном экране помещается большое количество данных

Примеры использованияStructureGantt

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

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

Есть несколько режимовStructure Gantt, которые я меняю в зависимости отконтекста, чтобы минимизировать объём работы.

Планирование и мониторинг проектов

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

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

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

Описание статуса проектатолько структура без диаграммыГантта

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

Планирование спринта

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

Мои любимыефичиStructureGantt

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

Связи между задачами

История декомпозирована,Jira-тикетына задачи заведены. На следующем этапе при растягиванииколбасокповременной ленте я расставляю связи междутикетами. Делаю так,чтобычётковыделить,какая задача заблокирована иликакиезадачи должны быть закончены одновременно (классические зависимостив управлении проектами:finishtostart,finishtofinish).

Цвета

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

Переход между режимами

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

Выбор за вами

Нам с коллегами Structure Gantt позволяет собирать всю нужную информацию из Jira в одном месте. Получается больше порядка и контроля над проектами.

При этом у Structure Gantt есть свои слабые стороны. Буду рада, если продакты ALM Works (создатели Structure) обратят внимание на них и сделают программу более простой и понятной в освоении.

Во время подготовки статьи я обнаружила, что функциональность Jira Roadmap заметно изменилась c лета прошлого года. Набор возможностей стал похож на то, что предлагает Structure Gantt.

Если выбираете приложение к Jira для ведения проектов и создания диаграмм Гантта, попробуйте оба варианта. Главное старайтесь оптимизировать затяжную механическуюработу.У насменеджеров есть много других важных задач, помимо рутины!:)

Ссылки

  1. Описание функционала на сайте Atlassian JiraRoadmap и StructureGantt

  2. Рекламное видео "What is Structure.Gantt?"

Подробнее..

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

08.06.2021 08:13:41 | Автор: admin

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

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

Поглядим, чему же программисты могут научиться у каменщика дяди Толи.

Исходная на стройке

На стройке работали три каменщика Костя, Рустам и дядя Толя. Косте было лет 25, Рустаму под 40, дяде Толе 50-60 (видимо, поэтому к его имени добавили уважительное дядя). Я, и еще человек 15 студентов и школьников, были разнорабочими принеси, подай, иди дальше, не мешай.

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

А теперь немного прервёмся и посмотрим, как дела у программистов.

Исходная на проекте

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

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

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

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

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

Процесс на стройке

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

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

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

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

Так и работали. Дядя Толя шёл примерно с той же скоростью, что Костя и Рустам вместе. Начальство не проявляло к работе дяди Толи никакого интереса. За Костей и Рустамом присматривали. Но, увы, не досмотрели.

А пока вернёмся к программистам и разработчикам.

Процесс на проекте

Программисты работали от проблемы. Сказали пользователям пишите, звоните, если чё не получается, будем вместе разбираться и решать. Когда их спросили, почему они не смотрят на систему в целом, те ответили чего на неё смотреть, она точно рабочая, мы её много раз внедряли. Это ж 1С:ERP. Там не всё гладко, но почти всё точно работает.

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

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

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

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

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

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

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

Но вернёмся на стройку.

Результат на стройке

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

Оставить-то они оставили. У дяди Толи всё, как задумано в проектной документации. У Кости и Рустама дырки под окна получились на разной высоте, с разницей примерно в полметра. И одно окно было смещено на метр в сторону.

Дядя Толя смеялся. Мы, разнорабочие, смеялись. Костя и Рустам махали руками и что-то громко кричали. Но прораб кричал громче, и некоторые слова даже можно процитировать. Например, зато, ***, кирпичи у вас только целые, и раствор, ***, свежий!.

А что у программистов с разработчиками?

Результат на проекте

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

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

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

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

Через две недели разработчики с аналитиками сбежали, как предыдущие черти. Кто в срочный отпуск, кто сказался больным или очень-очень занятым. Заказчик был в ступоре одно не работает, второе работает, но использовать нельзя (РПЗ запрещает).

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

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

Чем закончилось на стройке

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

Исправлял, естественно, дядя Толя. Костю и Рустама выгнали в тот же день.

А чем закончилось на проекте?

Чем закончилось на проекте

Директор собрал Большое Совещание. Со стороны подрядчика приехали программисты (разработчики с аналитиками, как мы помним, сбежали). Директор кричал и ругался, требовал объяснения и решения.

Когда проорался, программисты спросили так тебе объяснение или решение надо? Тот немного опешил, но сказал и то, и другое. Программисты спросили а в каком порядке? Сначала решение, потом объяснение.

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

Директор опешил чё, говорит, так можно было? И пристально посмотрел на РПЗ. Тот начал что-то тараторить, но директор его грубо прервал.

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

Подробнее..

Перевод Откровения кофеин-зависимого инженера как писать документацию

11.06.2021 22:17:41 | Автор: admin
image
Четыре вида документации распределнные по двум осям: практика-теория и обучение-работа.

Недавно вышли два нашумевших поста:



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

Я выпил достаточно кофе, и я попытаюсь объяснить то, что знаю.

TL; DR: пишите документацию для решения конкретной проблемы для определенной группы людей, а не только для того, чтобы документация была.

Пишите хорошо


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

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

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

Виды документации


Ладно, теперь вернемся к документации.

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

  1. Информация для обучения VS информация для работы.
  2. Практические шаги VS теоретическая информация.


(Это не моя мысль, я увидел это в https://documentation.divio.com/)



Информация для обучения, содержащая практические шаги, называется учебным пособием ( tutorial). Если она не содержит практических шагов, это объяснение (explanation). Оба из них, как правило, больше подходят для начинающих, поэтому им следует сосредоточиться на том, чтобы объяснять концепции и термины (и справочную информацию). Что касается объяснений, действительно полезно иметь краткий конспект вверху.

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

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

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

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

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

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

Почему


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

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

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

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

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

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

Нетехнический темы


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

Другие полезные нетехнические детали, включая:

  • Процессы, которым необходимо следовать (например, прежде чем обновлять что-то, отправьте электронное письмо в этот список рассылки, чтобы служба поддержки могла подготовиться).
  • Командная динамика. Та команда X действительно беспокоится о том, чтобы произошло Y, так что узнайте у них о Z
  • Информация о пользователях. У нас много пользователей, которые создали свои собственные штуки, и им не нужно менять свои штуки, поэтому мы делаем это обновление только для пользователей без специальных штук.
  • Интересные факты, например мы называем эту систему Нарнией, потому что ...


Туториалы


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

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

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

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

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

Гайды


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

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

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

Объяснение и справка


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

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

Практика документации


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

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

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

Пожалуйста, во имя всего святого, не пишите такую документацию:

/** * @param customer The customer * @param order The order * @return The price */public Price getPrice(Customer customer, Order order) {}


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

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

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

Один из способов сэкономить время превратить другую работу в документацию. Если вам нужно объяснить коллеге, как интегрироваться с вашей системой, скопируйте то, что вы пишете в Slack, в документ. Если вы написали проектную документацию, скопируйте несколько ее разделов в документацию и потратьте 10 минут на ее подготовку. Когда вам нужно что-то объяснить рецензенту в код ревью, объясните это с помощью комментария в коде, а не коммита в Github. Объясняет ли ваш тикет Jira, почему необходимо выполнить задачу? Круто, скопируйте это, и у вас есть документация. (Если это не так, заставьте спрашивающего написать это!)

Сообщите людям, куда обращаться, чтобы задать вопросы. Чтобы написать если у вас есть какие-либо вопросы, вы можете связаться с нами по адресу #team-channel в Slack, примерно за 15 секунд. Это поможет сэкономить часы, если вы запутаетесь. Довольно хорошая окупаемость на мой взгляд

Итак, кофе кончается, поэтому остановлюсь на этом.
Подробнее..

Перевод Разработчики не могут исправить ошибки управленцев

18.06.2021 12:04:53 | Автор: admin
Мне постоянно попадаются статьи, в которых разработчиков упрекают за нежелание вникать, зачем нужна их работа, и доказывают им, что это неправильно вслепую вносить изменения, не разбираясь, какая за этим стоит цель. Звучат призывы в духе оглянитесь вокруг, не уходите с головой в написание кода!. На мой взгляд, эти статьи обращены не к тем людям.

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

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

Организации, живущие по заветам университетских программ делового администрирования, избегают моделей с нефиксированными объемами работ. Им проще сосредоточиться на том, чтобы у технических команд было что-нибудь Готово к определенному сроку. Готово обычно бывает что-то никому не нужное, потому что вопрос об определении реальных потребностей аудитории замяли. Вдобавок в проекте обычно царит полный хаос, потому что команда раз за разом бросает силы на то, чтобы делать новый функционал, вместо того чтобы оценить свою работу и устранить тот самый хаос. Единственный плюс того, что проект довели до состояния Готово как правило, это событие отмечают пиццей и тортом. Если очень повезет, то еще и умеренным повышением кого-нибудь из команды, за то, что уложились в сроки. Правда, в реальности новым функционалом люди не пользуются, но это до поры до времени не имеет значения, пока в один прекрасный день кто-нибудь (как правило, финансовый директор) не посчитает KPI по формуле 4Х и не урежет команде финансирование.

В истории уже такое было


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

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

К 1981 году, когда Япония подтачивала позиции Форда на рынке уже десятки лет, руководство наконец сдалось и пригласило Деминга отладить производство. В их преставлении проблема заключалась в качестве изготовления деталей иными словами, в рабочих, которые изготавливали недостаточно качественные детали. Ведь не начальство же этим занимается. К большому их удивлению, Деминг заявил, что 85% проблем, негативно влияющих на качество продукции, происходят от неправильного руководства. Компании понадобилось шесть лет, чтобы перейти на новую модель, и результатом стала линейка автомобилей Taurus-Sable на голову выше того, что они делали до этого.

Основной ошибкой компании Форда было то, что, продумывая, как можно улучшить производство, руководство не обращалось к людям, которые занимались им непосредственно. Компании удалось значительно поднять качество продукции простым способом: менеджерам было поручено опросить рабочих на тему того, что и как можно делать лучше. Замечания выслушивались, а затем на их базе в процесс производства вводились новые практические усовершенствования. Раньше они использовали другой подход менеджеры сами придумывали абстрактные усовершенствования (зачастую с подачи начальства) и заставляли рабочих их внедрять. Сегодня мы наблюдаем тот же антипаттерн оптимизации сверху вниз в разработке ПО.

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

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

Авторы хотят как лучше и, на первый взгляд, вроде бы дают разумные советы. Но как именно эти самые работники автомобильной промышленности должны перекраивать рабочие процессы? Им предлагается переучивать начальство? В истории прецедентов особо не встречается, и я сильно сомневаюсь, что и сейчас это кому-то удастся. В подобной же ситуации оказываются и разработчики многих компаний. Большинство работает под игом выпускников по специализации делового администрирования. Каждый разработчик становится метафорическом винтиком в системе PMP/WBS всем по диаграмме Ганта, менеджеру проекта и индикатору типа задачи.

И даже когда компания, работающая по традиционной модели, решает переключиться на Agile, зачастую всё выливается во внедрение антипаттерна Date Scrum, который прекрасно уживается со стандартным подходом к руководству. Растущая популярность Date Scrum привела к тому, что у многих разработчиков сложилось неприязненное отношения к практикам Agile вообще. Их сложно винить: если до внедрения Agile им приходилось терпеть собрания с отчетом по текущим задачам раз в пару недель, то с Date Scrum приходится страдать ежедневно!

Что такое Date Scrum?
Это практика из сферы R&D, которая предписывает разработчикам оценивать проектные требования сразу для всей протяженности работ целиком. Когда проекту дают зелёный свет и утверждают бюджет на базе конечных оценок, команда каждый день собирается на встречах (скрамах), чтобы отчитаться по текущему положению и нейтрализовать рискованные моменты; таким образом решение итерируется по мере продвижения к дате релиза. Некоторые воспринимают этот подход как каскадную модель, только реализованную спринтами.

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

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

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

  • Разработчики, которые тратят вполне разумное количество дополнительного времени на то, чтобы проверить то, что сделано, и устранить хаос, считаются какими-то неспешными.
  • Разработчиков, которые замечают какое-либо несоответствие между продуктом и запросами рынка, мягко отправляют обратно за клавиатуру, строгать новый функционал. Всё, на что они могут рассчитывать обещание, что группа, генерирующая идеи, обо всём позаботится.
  • Разработчики, которые быстро выкатывают продукты на суд соответствующей сторонней группы, ценятся, потому что оперативно приводят всё в состояние Готово.
  • Разработчиков, которые ведут полевые наблюдения и видят, что пользователи испытывают трудности с продуктом, ненавязчиво возвращают в рамки общей программы.
  • Техлидов, которые пытаются вникнуть в Общую Картину (как продукт приспособлен к рынку, как определяются цены и состав пакетов услуг), похлопывают по плечу и отправляют обратно, мотивировать разработчиков на производство очередного функционала сомнительной полезности.
  • Разработчикам, которые пытаются держать ситуацию под контролем при помощи техник статистического управления хаосом, рекомендуют оставить всё это группе, ответственной за Качество как будто люди, которые не писали код, справятся с делом лучше!

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

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

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

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

Учитывая мнение разработчиков, руководство должно отказаться от следующих практик, которые плохо приспособлены для проектов, связанных с ПО:

  • Планирование по прогнозам, которое строится на дробной оценке сроков. Это годится для процессов, в которых точно известно время исполнения задач, разработка к ним не относится.
  • Дробная оценка сроков силами разработчиков.
  • Иерархическая структура работ опять же, хороша там, где точно известно время исполнения.
  • Определение дью исходя из некорректных оценок сроков.
  • Применение Agile Scrum, за исключением случаев, когда работа ведётся в связке с заказчиком, который в этом разбирается.
  • Некритическое принятие масштабов проекта, заявленных группой, которая генерирует идеи.

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

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

RPA инструменты и не только

06.06.2021 16:09:40 | Автор: admin

Однажды на работе мне поставили R&D задачу создать бота, который будет "ходить" по сайту, выбирать товары, заполнять формы и оплачивать покупки. На тот момент мы писали часть Antifraud системы, которая позволяла детектировать ботов в браузере. И с этого момента все началось...

Оглавление

  1. Коротко о RPA

  2. Open source проекты

  3. Платные сервисы

  4. Test Automation

  5. RPA vs Test Automation

  6. Парсинг сайтов и RPA

  7. BPM и RPA

  8. Безопасный RPA...

  9. Пример работы бота на Python

  10. Как детектировать бота?

  11. Выводы

Коротко о RPA

RPA (Robotic process automation) - это система, которая позволяет автоматизировать рутинные задачи (заполнение формы, перенос почты, и пр.), также можно сделать бота, который будет постоянно мониторить цены у конкурента, но это уже совсем другое... Если какое-то действие повторяется, то стоит задуматься над автоматизацией. Но не стоит пытаться автоматизировать все вокруг, хотя этого иногда очень хочется.

Более четкое определение:

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

За время создания своего бота я нашел несколько направлений RPA:

Направления в RPAНаправления в RPA

Open source проекты

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

RPA open sourceRPA open source

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

Selenium & rpaframework

Объединил 2 технологии в 1 короткий обзор т.к. использовал их для одной и той же задачи: создание бота, который выбирает товары, добавляет их в корзину и оплачивает покупки. Цель: сдетектировать и заблокировать бота, используя fingerprint и треки мыши. О том как детектировать ботов будет в разделе "Безопасный RPA...".

Selenium

SeleniumWebDriver это инструмент для автоматизации действий веб-браузера. В большинстве случаев используется для тестирования Web-приложений, но этим не ограничивается. Очень часто с помощью данного инструмента создаются различные боты.
Selenium IDE - инструмент для создания сценариев быстрого воспроизведения ошибок; расширение Chrome и Firefox, которая будет выполнять простую запись и воспроизведение взаимодействий с браузером.

RPA Framework

RPA Framework - это набор библиотек и инструментов с открытым исходным кодом для RPA, предназначенный для использования с Robot Framework и с Python. Имеет синхронизацию с Selenium и Playwright, библиотека для автоматизации Chromium, Firefox и WebKit с помощью единого API. Входит в набор инструментов Robocorp для автоматизации с открытым исходным кодом.

3 in 1 (Desktop / Web / Mobile)

Robocorp

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

TagUI

TagUI - бесплатный инструмент RPA от AI Singapore, финансируемой программой по ускорению развития ИИ. Проект TagUI является открытым и бесплатным. Его легко настроить и использовать, он работает в Windows, macOS и Linux.

TagUI RPATagUI RPA

Из всех инструментов мне больше всего понравился RPA Framework, у которого есть возможность работать с Playwright, также в этом фреймворке очень удобные selector в отличие от Selenium, что позволяет гораздо быстрее писать код.

Пример на Selenium и на RPA Framework

Selenium

from selenium import webdriverfrom selenium.webdriver.common.keys import Keysfrom webdriver_manager.chrome import ChromeDriverManagerdriver = webdriver.Chrome(executable_path=ChromeDriverManager().install())driver.get("https://www.google.com/")elem = driver.find_element_by_xpath("/html/body/div[1]/div[3]/form/div[1]/div[1]/div[1]/div/div[2]/input")elem.send_keys("Python news")elem.send_keys(Keys.RETURN)driver.close()

RPA Framework

from RPA.Browser.Playwright import Playwrightfrom Browser.utils.data_types import KeyActionlib = Playwright()lib.open_browser("https://www.google.com/")lib.fill_text(selector="input", txt="Python news")lib.keyboard_key(KeyAction.press, "Enter")lib.close_browser()

На мой взгляд у RPA Framework более удобное API.

Платные сервисы

Сказать что их много значит ничего не сказать. Платных Enterprise версий огромное количество. Но проблема в том, что многие организации не понимают истинной разницы в возможностях одного программного обеспечения RPA и другого. Возможно, они также слышали, что RPA предназначена только для очень крупных корпораций и что минимальные первоначальные инвестиции в лицензирование могут достигать 100 000 долларов в год, что теперь не всегда так.

RPA productsRPA products

Список ведущих поставщиков RPA на основе матрицы пиковых значений Everest Group для поставщиков технологий RPA 2020:

Everest группирует инструменты RPA в три основных сегмента в зависимости от их возможностей, влияния на рынок и способности успешно поставлять продукт. Everest также выделяет UiPath, Automation Anywhere, Blue Prism, Intellibot и Nividous в качестве лидеров.

UiPath vs Automation Anywhere vs Blue Prism

Компания Blue Prism, основанная в 2001 году, была пионером в секторе RPA и использовала термин Robotic Process Automation. Четыре года спустя генеральный директор UiPath Дэниел Дайнс технически основал UiPath как компанию под названием DeskOver. Однако только в 2015 году она действительно родилась и была переименована в RPA-компанию.

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

VSVS

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

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

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

  1. UiPath - 4.6 / 5 звезд с 4722 отзывами

  2. Automation Anywhere оценивает 4,5 / 5 звезд с 4310 отзывами

  3. Blue Prism 4,4 / 5 звезд по 158 отзывам

Что делает UiPath самой популярной платформой RPA?

UiPath превратился в единственную платформу RPA на рынке, созданную для поддержки полного жизненного цикла автоматизации. Портфель продуктов компании продолжает оставаться в авангарде инноваций, постоянно расширяя свои традиционные возможности RPA за счет включения таких инструментов, как интеллектуальный анализ процессов, встроенная аналитика, улучшенные компоненты AI Fabric, RPA на основе SaaS и автоматизация тестирования.

UiPath также считается одним из самых быстрых решений RPA в отрасли - часто в 3-4 раза быстрее, чем другие продукты RPA.

Другие ключевые сильные стороны UiPath:

  1. Long Running Workflows

  2. Machine Learning and Predictive Analytics

  3. Seamless Interconnectivity

  4. Process Document Understanding

  5. Citizen Development

  6. Customer Satisfaction

  7. Flexible Licensing Model and Low Cost of Entry

Оригинал статьи со сравнением: https://www.auxis.com/blog/top-rpa-tools

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

G2 GridG2 GridМини обзор популярных и не очень RPA

UiPath

Самое замечательное в UiPath - это простота использования.

UiPath прост в установке и имеет возможности разработки на основе пользовательского интерфейса. Подробное онлайн-руководство поможет быстро освоиться. Согласно Quadrant Review компании Gartner, UiPath имеет первоклассную команду поддержки клиентов, и в целом UiPath идеально подходит для компаний, стремящихся к быстрому внедрению RPA.

GUI UiPathGUI UiPath

Automation Anywhere

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

GUI Automation Anywhere GUI Automation Anywhere

Blue Prism

Blue Prism, старейший инструмент в индустрии RPA, в последние годы неуклонно растет.

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

GUI Blue PrismGUI Blue Prism

Microsoft Power Automate

Microsoft Power Automate предоставляет простое и эффективное решение RPA. Самым значительным преимуществом Microsoft Power Automate является простота настройки. Данные из экосистемы Microsoft легко доступны. Легко управлять оркестрацией робота.

WinActor

WinActor - это инструмент RPA, разработанный NTT Group. Он широко используется в таких отраслях, как разработка программного обеспечения и финансы.

GUI WinActorGUI WinActor

Test Automation

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

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

Automation Testing Tools

Инструментов ни сколько не меньше чем у RPA.

Вот небольшой список:

Инструмент

Open source

Платная

Selenium

+

Appium

+

SoapUI

+

TestProject

+

Cerberus Testing

+

Katalon Studio

+

IBM Rational Functional Tester

+

Telerik Test Studio

+

TestComplete

+

Ranorex

+

Kobiton

+

Subject7

+

HPE Unified Functional Testing (UFT)

+

Сводная картинка по некоторым инструментам:

QA Automation toolsQA Automation tools

RPA vs Test Automation

Коротко: это практически одно и то же.

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

Сходства:

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

Различия:

  • сценарии тестирования, созданные для автоматизации тестирования, зависят от тестируемой системы (SUT).

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

  • RPA инструменты не зависят от программного обеспечения, в котором запущен процесс.

Парсинг сайтов и RPA

Цели у компаний, которые занимаются парсингом сайтов, разные, но тем не менее такие инструменты есть и некоторые из них являются полноценным RPA инструментом (например, Octoparse).

Process Bots VS Search Bots

Process Bots VS Search BotsProcess Bots VS Search Bots

Сильные стороны RPA:

  • Low Code UX

  • Управление входами и выходами через UX

  • Работа с авторизацией для бизнес-приложений

  • Передача данных в бизнес-процессе

  • Бизнес-шаблоны для определенных шаблонов использования (обслуживание клиентов, финансовые таблицы и т.д.)

Сильные стороны поискового робота:

  • Масштабирование для одновременной обработки десятков тысяч страниц

  • Отсутствие конфигурации и автоматическая обработка для множества типов веб-страниц

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

  • Богатая индивидуальная конфигурация

  • Всестороннее чтение HTML страницы (Имя автора; UPC продукта)

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

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

Но какие боты лучше?

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

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

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

Теперь возьмем поискового бота с поддержкой AI. Вводим один сайт например, в Crawlbot Diffbot, ждем несколько минут, и тысячи страниц распознаются и анализируются как страницы продуктов. Загружаем данные в формате JSON или CSV, либо загружаем приложение или панель инструментов с выбранными результатами. Основная технология, лежащая в основе этого варианта использования, возможно будет чем боты RPA. Поисковые боты сами ускоряют чтение и классификацию Интернета!

Инструменты для парсинга

Scrape.do

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

Scrapingdog

Scrapingdog - это инструмент для очистки веб-страниц, который упрощает работу с прокси-серверами, браузерами, а также с CAPTCHA. Этот инструмент предоставляет HTML-данные любой веб-страницы за один вызов API. Одна из лучших особенностей Scraping dog - это наличие API LinkedIn.

ParseHub

ParseHub - это бесплатный инструмент веб-скребка, разработанный для извлечения онлайн-данных. Этот инструмент поставляется в виде загружаемого настольного приложения. Он предоставляет больше функций, чем большинство других скребков, например, вы можете очищать и загружать изображения / файлы, загружать файлы CSV и JSON. Вот список других его функций.

Diffbot

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

Octoparse

Octoparse выделяется как простой в использовании инструмент для парсинга веб-страниц без кода. Он предоставляет облачные сервисы для хранения извлеченных данных и ротации IP-адресов для предотвращения блокировки IP-адресов. Вы можете запланировать парсинг в любое определенное время. Кроме того, он предлагает функцию бесконечной прокрутки. Результаты загрузки могут быть в форматах CSV, Excel или API.

ScrapingBee

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

Luminati

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

Scraper API

Scraper API - это прокси API для парсинга веб-страниц. Этот инструмент помогает управлять прокси-серверами, браузерами и CAPTCHA, поэтому вы можете получить HTML-код с любой веб-страницы, выполнив вызов API.

Scrapy

Еще один в нашем списке лучших инструментов для парсинга - Scrapy. Scrapy - это платформа для совместной работы с открытым исходным кодом, предназначенная для извлечения данных с веб-сайтов. Это библиотека для парсинга веб-страниц для разработчиков Python.

Import.io

Инструмент для парсинга веб-сайтов с оперативным управлением всеми веб-данными, обеспечивая точность, полноту и надежность. Import.io предлагает конструктор для формирования собственных наборов данных путем импорта данных с определенной веб-страницы и последующего экспорта извлеченных данных в CSV. Кроме того, он позволяет создавать более 1000 API-интерфейсов в соответствии с вашими требованиями. Есть приложение для Mac OS X, Linus и Windows.

BPM и RPA

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

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

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

CAMUNDACAMUNDAСервисы BPM с интеграцией RPA

Camunda

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

Основные преимущества:

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

  • Согласование сценариев RPA

  • Оперативноенаблюдение задействиями ботов RPA

  • Аналитика RPA

ELMA

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

Выгоды длябизнеса отиспользования RPA + BPM:

  • Снижение издержек нарутинные операции.

  • Масштабирование бизнеса безрасширения штата.

  • Освобождение времени сотрудников наболее интеллектуальный труд.

  • Лучший Customer Experience засчет качества искорости сервиса.

ProcessMaker

ProcessMaker - это простое в использовании программное решение для управления бизнес-процессами (BPM) и рабочими процессами. Сочетает корпоративную разработку с низким уровнем кода и ведущую в отрасли интеллектуальную автоматизацию рабочих процессов.

Безопасный RPA...

Взлом RPA

Можно ли взломать RPA? Да, можно. Например, обработка данных с сайта (загрузка картинок, текста и пр.), откуда робот может скачать зараженный скрипт под видом обычной картинки, а скаченный скрипт может повлиять на работу бота, добавляя новые правила в обработку, или просто остановит его. Много что можно сделать, выбор огромный.

Риски безопасности, на которые стоит обратить внимание:

  • Риски выбора инструмента: выбор нужного инструмента от проверенного производителя. Компании обычно выбирают инструменты, не соответствующие их требованиям.

  • Операционные риски или риски исполнения: развертывание правильной операционной модели необходимо для уменьшения функциональных проблем или проблем с производительностью.

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

  • Раскрытие конфиденциальных данных:malware проникает в систему и создает сценарий при котором данные пользователей утекают в сеть.

  • Отказ в обслуживании: создания необходимых условия для остановки работы бота.

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

Проблема безопасности данных может быть разбита на два тесно взаимосвязанных момента:

  • Безопасность данных

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

RPA для пентеста

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

Продолжение следует...

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

Подробнее..

Как я пробовал внедрять DDD. Тактические паттерны

10.06.2021 14:04:32 | Автор: admin

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


Поначалу мне попали в работу легаси проекты, архитектура которых была Transactional Script или Table Module. Модули требовали рефакторинга, решения тех.долгов, встал вопрос о целесообразности рефакторинга и альтернативных реализаций. Как инженер, я решил, что единственный верный шаг прокачать себя, а затем и команду, теоритически, а потом предпринимать стратегические шаги. Если с TS и TM архитектурами я был хорошо знаком, то шаблон Domain Model был знаком только в самых общих чертах по книге Мартина Фаулера. На фоне общения на конференциях, чтения матёрых книг про рефакторингу, SOLID, Agile, пришло понимание почему именно изучение подобных архитектур оправдано: в Enterprise есть смысл стремиться к максимально адаптируемому к изменениям ПО, а для доменной модели изменения требований стоят несравнимо дешевле в реализации. И меня напрягало, что как раз доменные модели я если и применяю, то понаитию, бессистемно, невежественно. Так началось моё знакомство с предметно-ориентированным проектированием.


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


Тактические паттерны


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


Доменная модель


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


  1. Абстрактная модель. Публичные интерфейсы модели, которые могут быть доступны в других слоях. Сами интерфейсы пишутся так, чтобы они наследовали интерфейсы из нашего Seedworks, что позволяет избежать зоопарка в различных проектах. Абстрактная модель первое с чего начинается любой сервис, т.к. содержит в себе ОБЩЕУПОТРЕБИМЙ ЯЗК.
  2. Реализация модели. Internal реализация агрегата, содержатся необходимые проверки, скрываются фабрики, бизнес-методы, утверждения и т.д.

Реализация агрегата


Команда рассматривала следующие способы реализации агрегата:


  1. Свойства с модифицированными set'ерами, в которых сокрыта логика обнаружения изменений. Код получается неоправданно усложнённым, и не совсем понятно зачем. Мы имели такую реализацию, когда ещё оперировали анемичной моделью (вспоминаю как страшный сон).
  2. Aggregate Snapshots. Механизм делает регулярно или по триггеру снимки агрегата и, если что-то поменялось, регистрируется событие.
  3. Иммутабельные агрегаты, порождающие через бизнес-методы новую версию агрегата. В нашей команде прижился 3й вариант он сулит самые большие перспективы для распределённой системы.

Итак, строение агрегата.


  • Анемичная модель. Анемичных модели у нас две: обычная, и "дефолтная", с пустыми объект-значениями и корнем. При этом анемичная модель условная часть агрегата, существующая только для организации жизненного цикла данных, т.е. в репозитории, фабриках.
    • Идентификаторы. Мы используем составной ключ <guid, long>. Первая часть идентифицирует агрегат, вторая его версию.
    • Корень агрегата. Обязательная сущность, вокруг которой и строится ограниченный контекст. С этим элементом у нас были проблемы, мы ожидали что корень будет иммутабельным на всём протяжении жизненного цикла агрегата, однако, практика показала другое, нежели в книгах. Позже слышал на DDDevotion от Константина Густова то же самое.
    • Объект-значения. Простой иммутабельный класс: конструкторы закрыты, фабричные методы открыты.
  • Бизнес-методы. В нашей реализации составной объект, состоящий из предусловий и постусловий. Результат выполнения операции усложнённая монада Result или сложная структура, возвращающая две анемичных модели и результат операции. Результаты операций на данный момент делим на:
    • Успешные.
    • Ошибочные по бизнес-проверкам, которые могут порождать новую версию агрегата, однако, могут иметь место проблемы с постусловиями.
    • Фатальная проблема, когда предусловие говорит о том, что данная операция не может быть выполнена.

Доменные сервисы


Этот слой ответственен за работу с агрегатом. Состоит двух механизмов:


  • Нотификатор доменных сообщений. Декорирует методы агрегата, реализуя его абстракцию. Данный механизм служит для обработки анемичной модели до вызова новой версии анемичной модели и результата операций. Из этих сообщений формируются доменное событие, которое жёсткой схемой отражено в SeedWorks и реактивно помещается в Шину Доменных Событий.
  • Провайдер агрегатов. Данный механизм инкапсулирует репозитории и фабрики, т.е. служит для получения по идентификатору агрегата и поддержки жизненного цикла агрегата. Задача провайдера построить агрегат из анемичной модели, декорировав его методы нотификатором.

Сначала мы пытались реализовать поиск через провайдер с применением спецификации, однако, отловили проблемы с EF. Эти проблемы застали думать о CQS. Теперь CQRS+ES у нас из коробки, т.е. доменные события отражаются на материализованных представлениях, и, в свою очередь, с их помощью происходит поиск нужного агрегата. В случае если агрегат не найден в мат.представлениях, провайдер соберёт агрегат с пустой моделью это удобно тем, что бизнес-методы всегда остаются внутри агрегатов.


Слой приложения


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


Слой сервисов


С сервисами всё интересно. По умолчанию, мы продолжаем использовать .NET Core Web API, т.е. REST, протокол. Однако, REST это про архитектуры TableModule и нельзя использовать глаголы PUT, DELETE для модифицирования агрегата. Контроллеры наших микросервисов повторяют методы агрегата, используя глагол POST, ведь для стратегических паттернов нужны идемпотентные операции. В итоге получается дисфункция использования контроллеров. Возможно, следует использовать gRPC.


Инфраструктурный слой


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


Хранилище и материализованное представление напрямую не привязано к агрегату. Вместо этого, они прослушивают ШДС(шину доменных событий), асинхронно обрабатывая эти события. Из этого не трудно понять, что ШДС становится для нас механизмом масштабирования.


Как это выглядит в итоге


С одной стороны:


Описание Зарисовка
Гексогональная архитектура микросервисов, декомпозированных по субдомену. image
Команда над доменной сущностью порождает новый объект (версию). image
Сравнение версий агрегата и метаданные команды (источник доменного события). image
Для распространений изменений используется ШДС, что открывает возможности для CQRS и ES. image
Версионирование команд и агрегатов должны помочь избежать блокировок и перепроверок при помощи оптимистичных блокирок. Появлется возможность ветвлений-сессий. image

С другой стороны:


  1. Тактические паттерны освоены костяком команды. Каждый может вести свою команду, распространять подход дальше.
  2. Наработки позволяют начинать работу с контестом даже если единый язык беден, оставив от модели лишь корень. По мере уточнения общеупотребимого языка, модель будет расширяться.
  3. Из всех взятых в работу ограниченных контекстов генерируются доменные события пригодные к использованию в смежных ограниченных контекстах.
  4. Предметная сложность полностью в модели. Даже инфраструктурных сложностей нет как таковых понятная работа по материализованным представлениям, обработчикам слоя приложения. Вместе с решением технической сложности, появляется soft-slills сложности.

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




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

Подробнее..

Книги, которые повлияли на меня как на разработчика и управленца

18.06.2021 12:04:53 | Автор: admin

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

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

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

Практика

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

Specification by Example

Книга понравилась мне настолько, что побудила написать первую статью на Хабре. Гойко Аджич автор книги сам описывает ее как книгу о разработке ПО без единой строчки кода. Ее фокус находится на пересечении управления требованиями, проектного менеджмента, DevOps и тестирования (в том числе автоматизированного). Если DevOps часто описывают как infrastructure as code, то Specification by Example это своего рода requirements as code. Проработав некоторое время в корпоративном сегменте индустрии любой разработчик рано или поздно узнает о том, насколько неполными, неточными, противоречивыми и устаревшими бывают требования и насколько сложно, долго и дорого бывает переделывать программы, написанные по таким требованиям. Существуют тяжелые методы борьбы с этим недугом. Например ГОСТ 34 до сих пор используется в госсекторе, несмотря на то, что он безнадежно устарел.

Specification by Example гораздо более гибкая и менее формальная техника, позволяющая, впрочем, заказчику и исполнителю говорить на одном языке, понятном обоим. Кроме того, ГОСТы описывают форму проектной документации, но не дают конкретных советов по проектному управлению и никак не поощряют коммуникацию и совместную работу по улучшению требований и нахождению лучших (более быстрых, качественных и дешевых) способов решения проблем. Примеры переформулированных требований из книги гарантированно не оставят вас равнодушными. Техникой контрольных примеров мы пользуемся уже восемь лет, и она позволяет экономить какое-то невероятное количество времени и избегать недопониманий.

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

Event Storming

Это даже не книга, а своего рода комикс. Если вы любите стикеры, доски и kanban, то event storming скорее всего тоже зайдет. Со временем мы пришли к тому, что большинство web-проектов сразу создаем на основе CQRS-архитектуры, даже если на старте хранилище данных всего одно. Это позволяет по мере развития проектов независимо оптимизировать стеки чтения и записи. И в момент, когда запросы к БД становятся уже совершенно безобразными, воткнуть очередь с денормализоваными хранилищами.

Подробно о всех преимуществах CQRS перед классической n-layer- и onion-архитектурой я рассказывал в докладе Быстрорастворимое проектирование.

Причем здесь Event Storming? Это техника специфицирования в терминах DDD, CQRS и Event Sourcing в форме увлекательной игры со стикерами, фломастерами и доской (доска может быть физической или виртуальной, но с физической гораздо веселее). С точки зрения наглядности, метод не успевает за Activity и BPMN-диаграммами. Но он гораздо более легковесный и прост в освоении и понимании.

Impact Mapping

И снова книга Гойко Аджича. Часть идей в ней пересекается со Specification by Example, но у книг разные целевые аудитории. Spec by Example лучше подойдет для разработчиков, архитекторов, тестировщиков, аналитиков и менеджеров среднего звена. Impact Mapping инструмент, в первую очередь, для бизнеса: владельцев продукта (или даже компании), маркетинга и топ-менеджмента. Spec by Example лишь поощряет общение с целью поиска оптимальных решений. Impact Mapping это формальный процесс для стратегического планирования. Его можно использовать не только в разработке ПО, но и для стратегического планирования, в целом. Например, в этом году мы использовали Impact Mapping для приоритизации и планирования задач в HR.

Теория + практика

Теоретически-практические книжки чуть более сложные. Я бы рекомендовал начать с DDD это очень холиварная тема! Возможно, DDD это не то, что вам нужно на этапе создания стартапа, но попробуйте обратить внимание не на технические аспекты, а на высокоуровневые паттерны. На то, как DDD предлагает общаться с экспертами, выделять главное, и на то, что продукт порой важнее используемых технологий. Если вам это зайдет, то дальше начнется протоптанная другими тропа: DDD -> CQRS -> Event Sourcing. Чаще всего все эти три темы обсуждаются в одном комьюнити. Как только вы разберетесь, что собой представляет каждая из концепций, вы поймете почему.

Немного особняком стоит книга Скотта Влашина про DDD в мире функционального программирования. Во-первых, ФП в изложении Влашина это не сложно. Обратите на книгу внимание хотя бы поэтому. Во-вторых, даже если в ближайшие десятилетия вы не собираетесь никуда сворачивать с тропинки объектно-ориентированного программирования, изучение других способов решения знакомых проблем может быть точкой роста. Я большой фанат гипотезы лингвистической относительности (и фильма Прибытие удачно выигрывающего эту гипотезу). В каком-то смысле знание языков программирования может влиять на ваше мировоззрение также, как знание естественных языков.

Теория

Факты и заблуждения профессионального программирования

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

Мифический человеко-месяц

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

Сколько стоит программный продукт

Большинство знает другую книгу МакКонела Совершенный код. Для кого-то она даже стала своеобразной Библией программирования. Если вы уже программируете хорошо и хотите научиться лучше оценивать трудозатраты на разработку, прочтите Software Estimation: Demystifying the Black Art (Сколько стоит программный продукт; в оригинале название звучит точнее, не находите?:). Книжка сложная, со статистикой, но ничего лучшего об оценке я не видел. Гарантирую, качество оценки тех, кто использует методы и советы из книги, многократно превосходит качество оценки тех, кто делает это по наитию.

Лютая теория и даже философия

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

Цель. Процесс непрерывного улучшения

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

На этом мой список книг подходит к концу. Выбирайте полезные для себя и enjoy!

TechLead Conf 2021 конференция, полностью посвященная инженерным процессам и практикам откроет свои двери уже совсем скоро: 30 июня и 1 июля она пройдет в Radisson Slavyanskaya (Москва).Расписаниеуже готово.Билетыв продаже. А ещё у нас открытдоступк докладам TechLead Conf 2020.

До встречи в офлайне!

Подробнее..

Кто, где, когда система компонентов для разделения зон ответственности команды

09.06.2021 18:07:37 | Автор: admin

Меня зовут Евгений Тупиков, я ведущий PHP-разработчик в Badoo и Bumble. У нас в команде более 200 бэкенд-разработчиков, которые работают над сотнями модулей и отдельных сервисов в наших приложениях. Но поначалу всё было не так масштабно. В 2006 году это был один проект, над которым работала небольшая команда. Каждый разработчик хорошо понимал, как всё устроено: легко ориентировался в коде, знал, какие есть сервисы и как они взаимодействуют между собой. Однако по мере роста проекта всё больше времени занимал поиск хранителей знаний тех, кто отвечает за ту или иную функциональность и к кому можно обратиться с вопросом или предложением.

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

Предыстория

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

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

  • @team команда, ответственная за данную часть системы;

  • @maintainer человек, разрабатывающий данную функциональность (таких сотрудников может быть несколько).

/** * @team Team name <team@example.com> * @maintainer John Smith <john.smith@example.com> * @maintainer .... */

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

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

Нам же хотелось иметь возможность обновлять список ответственных в одном месте. И желательно, чтобы все остальные системы автоматически подхватывали изменения.

Так мы пришли к компонентному подходу.

Что такое компонент

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

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

При переходе на компонентный подход мы сформировали ряд правил и ограничений:

  • структура компонентов должна быть линейной;

  • каждая команда должна иметь свой набор компонентов (один и тот же компонент не может относиться к нескольким командам);

  • для каждого компонента должен быть задан список ответственных, при этом оптимальное количество ответственных за один компонент двачетыре человека;

  • только менеджер или тимлид команды может добавлять и удалять компоненты;

  • у каждого компонента должен быть уникальный идентификатор (alias).

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

Пример страницы компонента в интранете Пример страницы компонента в интранете

Мы видим, что у компонента есть:

  • уникальный идентификатор;

  • email;

  • название команды, которая отвечает за данный компонент;

  • название проекта, к которому относится компонент, в Jira;

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

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

Как мы используем компоненты в коде

Докблок файла

/** * @component component_alias */

Мы доработали Git hook, проверяющий докблок. Он следит за тем, чтобы файлы, в которые были внесены изменения, содержали тег @component и чтобы указанный компонент существовал.

remote: ERROR in SomeClass.php:        remote: * Unknown @component: UnknownComponent. You have to create component before using it in the code   

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

Сервис для работы с компонентами в коде

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

$componentManager = new \Components\ComponentManager();$component = $componentManager->getComponent('component_alias');$recipients = [];foreach ($component->getMaintainers() as maintainer) {    $recipients[] = $maintainer->getEmail();}

или найти дежурного по компоненту:

$componentManager = new \Components\ComponentManager();$component = $componentManager->getComponent('component_alias');foreach ($Component->getMaintainers() as $maintainer) {    if ($maintainer->isDuty()) {        return $maintainer;    }}

Интеграция с PhpStorm

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

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

Дежурный по компоненту

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

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

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

Кроме того, дежурства позволяют делиться знаниями внутри команды, тем самым повышая bus factor.

Интеграция с внутренними системами

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

Система сбора и анализа PHP-ошибок

Исторически для сбора и анализа PHP-ошибок мы используем самописную систему, которая по функциональности похожа на популярные Sentry и Splunk, но адаптирована к нашим внутренним процессам. В неё первую мы добавили поддержку компонентов.

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

Эту информацию можно использовать:

  • для поиска ошибок по определённому компоненту;

  • для построения отчётов и графиков в разбивке по компонентам.

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

Реестр баз данных

Бэкенд наших приложений Badoo и Bumble состоит из сотен различных модулей, систем и сервисов. Большинство из них для хранения данных использует MySQL.

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

  1. Найти в коде, на каком хосте живёт база.

  2. Подключиться к хосту через любой удобный инструмент (консольная утилита, phpMyAdmin, Sequel Pro, IDE и т. д.).

  3. Найти нужную базу и таблицу.

  4. Изучить информацию о таблице.

А если нужно узнать размер таблицы на продакшене?

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

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

Чтобы упростить жизнь разработчикам, мы создали систему под названием DBRegistry. Она хранит в себе информацию для всех баз данных, доступную через INFORMATION_SCHEMA.

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

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

Заключение

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

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

На этом всё. Спасибо за внимание!

Подробнее..

MVP на примере швейцарского ножа

04.06.2021 14:18:19 | Автор: admin

MVP (minimum viable product) - это первая версия вашего продукта, с помощью которой вы, как создатель продукта:

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

  • собираете обратную связь от ваших будущих пользователей;

  • пытаетесь продать (или уже продаёте) ваше решение пользователям.

Пройдёмся по этим пунктам.

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

Однажды люди нащупали гипотезу, которая могла явиться проблемой: что если я оказываюсь в диком лесу, и мне нужно срезать гриб и отметить это, выпив бутылку шампанского? Носить с собой штопор и нож - попросту неудобно (да и кто в здравом уме берёт с собой в лес штопор?). Что, если объединить эти инструменты в одно?

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

Представим, что у них это получилось. Что им делать в таком случае?

  1. продолжать продавать текущее решение, параллельно добавляя туда новые инструменты (функции), опираясь на обратную связь и пожелания покупателей;

  2. совершенствовать текущее решение, делать его более удобным (работать над UX);

  3. собирать обратную связь от пользователей и корректировать продукт.

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

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

Как это можно сделать?

  1. Производить и пытаться продать совсем маленькие партии;

  2. Экономить на качестве (но не так, чтобы получилось совсем плохо).

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

Как отбирать гипотезы и функции

Гипотеза - это предположение о проблеме клиента.

В одной версии продукта стоит тестировать только одну гипотезу за раз. При этом гипотеза должна быть смелая. Хотят ли люди есть грибы? Определенно да! Готовы ли пить шампанское? О да! Но может ли кому-то внезапно понадобится и нож, и штопор одновременно? Это уже гипотеза, которую стоит протестировать!

Теперь перейдём к тому, что можно включить в первую версию продукта. Ответ прост: нужно включать те функции, которые:

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

2) дают наибольшую ценность для пользователя. Да, в швейцарский нож можно напихать ещё и трекер шагов, и bluetooth колонку, но основную ценность в нашем примере имеет нож и штопор.

Все функции, которые не удовлетворяют этим требованиям, можно смело оставлять на будущее.

Валидация без продукта

Можно ли подтвердить гипотезу относительно продукта, совсем не создавая никакого решения?

В IT-сфере - можно, если быть чуть хитрее и умнее, чем наши фаундеры из примера.

К примеру, они могли создать лендинг Чудо Швейцарские Ножи, повести на него трафик из социальных сетей, и посмотреть, оформляют ли люди предзаказ на этот товар. Если да - то его можно производить.

Примеров таких предзапусков в истории множество, но вот мой любимый:

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

К слову, я даже пытался подобрать правильные ответы к анкете, чтобы получить доступ. И у меня это получилось! Но то, что оказалось внутри, мне уже было не интересно (не зря же я подбирал ответы).

Продавать или нет?

Автор книги Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели Эрик Рис говорит, что MVP с первого дня должен продавать. И я с ним абсолютно согласен.

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

Ошибки при разработке MVP

MVP - это непаханное поле для больших ошибок и слитых бюджетов!

Вот какие ошибки вы можете совершить по ходу пьесы:

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

  • Не слушать обратную связь от пользователей. Если вы не проводите тестирования и не слушаете обратную связь от пользователей, то вообще непонятно, зачем вы затеяли MVP. Возможно, вам стоит сразу пилить полноценный продукт и оказаться без миллиона в кармане?

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

  • Недостаточно стараться. Можно придумать отличную идею совместить нож со штопором, но если сделать это в стиле и таааак сойдёт!, то вы рискуете, что ваш пользователь окажется без руки, пользуясь вашим чудом техники. Перефразирую: в 21 веке уже недостаточно сделать косое и кривое приложение. Аппетиты и желания клиентов растут, поэтому постарайтесь, чтобы ваша первая версия выглядела хотя бы симпатично.

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

Подробнее..

Навык для Алисы Проведи стендап

02.06.2021 20:09:34 | Автор: admin

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

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

Так я написал навык Проведи стендап.

О навыке

Возможности

  • Добавление/удаление людей из команды. Какой стендап без команды? Для того, чтобы навык знал о составе вашей команды, есть фразы: Добавь в команду ИМЯ [ФАМИЛИЯ], Удали из команды ИМЯ [ФАМИЛИЯ] и дополнительная фраза Добавь в команду человека ИМЯ [ФАМИЛИЯ]. Зачем нужна ещё одна фраза будет описано в разделе про интенты. Достаточно сделать это один раз - информация о команде сохранится.

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

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

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

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

Разработка

Сам по себе навык - простой веб сервер с одним обработчиком, куда поступают все запросы с репликами пользователей. Я реализовал этот сервер на питоне через Flask. В качестве базы данных была выбрана PostgreSQL.

Хотелось бы отметить 2 возможности, которые Яндекс предоставляет для навыков:

Интенты

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

Если какой-либо интент нашелся, то из него можно вычленить определенные сущности, как вариант имя и фамилию человека. Но тут возникает проблема: Имя и Фамилия - заранее определенные сущности, поэтому какую-нибудь редкую фамилию Яндекс может и не распознать. Для этого и была создана дополнительная фраза, позволяющая добавить человека в команду. Также использование интентов осложняет тестирование. Работу самих интентов можно протестировать при создании в консоли разработчика навыка. Но, при написании своих тестов к основе навыка (в моём случае - обычному веб-серверу на питоне, как уже упоминалось выше), нужно писать свой обработчик языка, иначе эти интенты не будут распознаны.

Авторизация

Яндекс.Диалоги предоставляют возможность авторизации через навык в сторонних сервисах, поддерживающих OAuth. Однако по неизвестным причинам прикрутить авторизацию в гитхабе у меня не получилось, и поддержка не смогла помочь с поиском проблемы. В итоге авторизация в гитхабе проходит через Github App. Чтобы она работала, нужно установить приложение в свой репозиторий, и тогда авторизация и работа с гитхабом идут уже от лица приложения. С трекером Яндекса вышло проще - OAuth авторизация заработала без проблем. Но есть один минус - OAuth авторизация поддерживается максимум только для одного сервиса. (Поэтому, если бы получилось сделать авторизацию для гитхаба, пришлось бы делать костыли для авторизации в трекере).

Итоги

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

Репозиторий

Навык

Подробнее..

Как масштабировать разработку при 400 000 RPM и не надорваться

04.06.2021 16:20:58 | Автор: admin
Если бизнес идет вверх, тозапросы инагрузка наразработку увеличиваются вразы. Рано или поздно каждый управленец сталкивается свыбором издвух крайностей: встать насторону бизнеса, двигать продукт идемотивировать разработчиков бесконечным техдолгом или дать свободу разработке ипотерять контроль над задачами бизнеса.

Mindbox 15лет развивает B2B-продукт ивырос с3до70человек вразработке. Мытестировали разные подходы кмасштабированию иготовы поделиться опытом, чтобы вам непришлось наступать натеже грабли. Ниже расскажу, как попробовали полную автономию команд ицентрализацию, роняли надежность, демотивировали команды, как врезультате сэтим справились ивыработали свою систему масштабирования.

По материалам выступления на Agile Days 2021:



Надежность как ядро разработки


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

ВMindbox одна изсамых нагруженных разработок вРоссии, нопри этом она сохраняет высокую надежность. Когда покупатель пробивает чек накассе вБургер Кинге или аптеке Ригла, транзакция идет кнам. За200 миллисекунд мырассчитываем суммы иотвечаем кассе. Если сервис упал, томного людей повсей стране 24/7 становятся несчастны.

Запоследние 34 года бизнес растет по4050% вгод инагрузка удваивается ежегодно. Внешне всё отлично, ноуMindbox был длинный период становления, который влиял намасштабирование разработки.

Масштаб бизнеса и разработки




Эволюция разработки




Как работает автономия ицентрализация разработки


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

  1. Автономия. Вомногих компаниях победили автономные инженеры инет никаких сроков. Разработка постоянно закрывает секретный техдолг, абизнес непонимает, как решать крупные задачи. Это заканчивается революцией: бизнес теряет терпение ивносит радикальные изменения впроцессы.
  2. Централизация. Другая крайность когда побеждает бизнес. Дедлайны спускаются наразработку сверху, задачи бизнеса решаются, нокопится техдолг. Потом процессы опять замедляются иистория заканчивается революцией: предлагают переписать код снуля или продать компанию.

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

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

Как внедрили автономию


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

Дали автономию командам. Постепенно бизнес стал прибавлять по4050% вгод, поэтому нужно было запускать больше продуктов ипродвигаться быстрее. Втоже время мыначали строить бирюзовую культуру, прочитали книгу Лалу ирешили, что нужны автономные продуктовые команды сменеджерами продуктов. Иэто заработало запустили новые продукты.

Бирюзовая компания вРоссии: открытые зарплаты, самоуправление, прозрачность иошибки
Фредерик Лалу: Открывая организации будущего

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

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

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

Как внедрили централизацию


Централизовали управление. Прочитали книгу оLeSS (Large Scale Scrum), сходили натренинг ирешили централизовать разработку: внедрить общий roadmap, единое управление иразгрумить эпик надежности.

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

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

Так мысоздали роль CTO (chief technical officer), хотя доэтого небыло менеджмента, отвели30% ресурса натехдолг ивнедрили LeSS. Это значит, что70% разработчиков занимались roadmap бизнеса, а30% техническим roadmap, который определяет CTO. Врезультате техдолг начал сокращаться, имыувидели положительные изменения.

LeSS Scrum набольших масштабах

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

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

Главное, что год мыпрожили врежиме LeSS изаметили негативные эффекты для компании. Инженеры именеджеры попродукту были демотивированы. Уинженеров небыло домена ичувства собственности, как увавтономных команд: три месяца они работали над одним продуктом, потом три месяца над другим. Менеджеры попродукту загрустили, потому что roadmap планируется централизованно иtime tomarket стал огромным. Нельзя было взять ивнедрить небольшую доработку для клиента, потому что roadmap управляют централизованно.

Как нашли баланс между автономией ицентрализацией


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

Вернули команду инфраструктурной платформы. Фактически инфраструктура это тоже внутренний продукт, аCTO выполняет роль менеджера попродукту, поэтому выделили отдельную команду под инфраструктуру.

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

Оставили30% ресурса команды налокальный техдолг. Мыдоговорились одвухуровневом разделении. Наверхнем уровне30% всего ресурса разработки отдали CTO наинфраструктурную команду итехнический roadmap. Ещё30% отдали натехдолг, который приоритезирует команда. Фактически смомента, когда начались проблемы снадежностью имасштабированием, почти50% всего ресурса это технические задачи.

Техдолг ~30% платформы и 30% команды


около 50% в целом



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

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


Из LeSS оставили кросс-командный рефайнмент, чтобы снять риск монолита и управлять roadmap

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

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

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




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

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

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

Виртуальная команда (круг) управления




Ритуалы управления



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


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

Мызнали, что скорость иroadmap нельзя измерять, потому что есть проблемы стехдолгом иэто только демотивирует разработчиков. Науровне стратегии разработки мысформулировали, что цель разработки оптимизировать непрерывный запуск продуктов (time tomarket) врамках ограничений надежности, стоимости железа ибез увеличения технического долга. Ировно такиеже ожидания сформировали для команды. Команда должна непрерывно поставлять фичи, увеличивать time tomarket, нопри этом поддерживать определенные обязательства понадежности, SLA истоимости.

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

Показатель эффективности


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


Какую выработали систему масштабирования разработки


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

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

Кто такой QA Engineer, QC Engineer и Software Engineer in Test

17.06.2021 10:17:44 | Автор: admin

Я недавно латала дыры в понимании разницы между Quality Assuarance и Quality Control. Статей на эту тему много, я накидала свой вариант, хотелось по существу. Делюсь с вами. Enjoy, если актуально!

Кто такой QС Engineer

Контроль качества (QC) - часть международного стандарта управления качеством ISO 9000. Суть контроля качества сводится к поиску дефектов и ошибок после создания продукта.

Таким образом, специалист, чья работа крутится вокруг тестирования - это QC Engineer, по-русски, тестировщик.

Должностные обязанности QC Engineer

Примерный обобщенный список:

  • Оценка и внедрение программного обеспечения для тестирования.

  • Проверка продукта на соответствие установленным требованиям и ожиданиям.

  • Настройка автоматического тестирования.

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

  • Проверка, что конечный продукт соответствует стандартам компании, стандартам отрасли, законам.

  • Составление отчетов об испытаниях и проверках.

  • Выявление и документирование ошибок и дефектов, которые необходимо исправить перед выпуском продукта.

  • Выявление и документирование ошибок и дефектов, которые можно исправить после отправки продукта.

  • Тестирование инструкций, гайдов, документации.

  • Работа со специалистами по обеспечению качества.

  • Оценка отзывов и жалоб клиентов -- поиск и рекомендации решений, которые сделают их счастливыми.

  • Мониторинг поступления на рынок только высококачественной продукции.

Кто такой QA Engineer

Обеспечение качества (QA) - часть международного стандарта управления качеством ISO 9000, которая помогает компаниям соответствовать требованиям, удовлетворять потребностям клиентов и постоянно улучшать свои процессы и процедуры.

Должностные обязанности QA Engineer

Примерный обобщенный список:

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

  • Документирование и обновление типовых инструкций и лучших решений (best practices).

  • Проверка процессов, процедур и документации на соответствие правилам и стандартам.

  • Мониторинг текущих процессами с целью их улучшения.

  • Обучение производственных и инженерных групп соблюдению установленных процессов и процедур.

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

  • Сбор и оценка отзывы клиентов.

ВАЖНО. Даже если в компании есть четко определенная позиция QA Engineer, обеспечивать качественный процесс, создавать качественный продукт остается обязанностью каждого участника команды.

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

Разница между QA и QC

Кто такой Software Engineer in Test

На моей текущей работе недавно сменился босс и он регламентировал, что QA - полностью обязанность каждого сотрудника, а я для них Software Engineer in Test.

При ближайшем рассмотрении Software Engineer in Test у меня получилось, что это тоже QC Engineer с одной лишь разницей, что фокус его обязанностей в автоматизации тестирования и включает и разработку собственного фреймворка/инструмента, и написание автотестов:

  • Создание/расширение фреймворка для тестирования.

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

  • Настройка и поддержка тестового окружения.

  • Настройка автоматизированных тестов для надежного и эффективного выполнения в средах CI / CD.

  • Обеспечение оптимального покрытия автотестами на всех уровнях.

  • Автоматизация отчетности.

  • и т.п.

Обязанности второго плана по сути копируют список QC Engineer.

Заключение

Итак, в любой компании есть Quality assuarance - это обязанность каждого сотрудника работать на высокое качество, но может присутствовать QA Engineer, который держит улучшение процесса разработки в постоянном фокусе.

И есть Quality Control. В центре QC - различные виды тестирования и все, что с этим связано, поэтому это зона ответственности Тестировщика, QC Engineer и Software Engineer in Test.

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

Но кем бы вы ни были совместным итогом поступательных шагов в QA и QC всегда будут:

  • высококачественный продукт на выходе

  • приятный процесс работы и профессионализм

  • доверие и приверженность клиентов

  • отсутствие серьезных дефектов в продукте

  • оптимизация ресурсов и снижение затрат

Удачи!

Подробнее..

Вместе лучше

17.06.2021 08:13:07 | Автор: admin

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

День обещает быть насыщенным, вот только ночью Лиза полночи крутилась в постели, никак не могла уснуть. В какой-то момент, она, все-таки, провалилась в сны. И теперь сны эти призрачной тенью ходят за ней, не отпускают мысли. Сначала ей снилось, что она сидит в яме. А сверху монстры. Глядят на нее, не уходят. Один норовит ей руки откусить, второй вот-вот в сердце клюнет, а потом еще и третий подошел, камень на нее толкает запереть хочет. Лиза зажмурилась, руки перед собой выставила, стала думать как из ямы выбираться. Но тут стало светло. Огляделась, а сон уже другой. Вокруг облака, она на горе, вверх лезет. Смотрит, над ней опять монстр, камни мелкие в нее кидает, за ним второй огнем дышит, вперед не пройти. Рядом крутой склон не ухватиться. Неизвестно еще что хуже - в яме пропасть или с горы сорваться. Вдруг стук прямо перед ней кто-то вбивает скальные крючья для страховочного троса. Не разглядеть кто, просто силуэт. И тихим голосом ей в самое ухо обещает: "Прорвемся". Тут Лиза замечает, что на поясе у нее как раз тот самый трос страховочный цеплять себя за крюки.

С еще не отпустившим мозг облегчением Лиза проснулась и пошла собираться.

И вот первое собеседование. Коленки дрожат, слова путаются. Но лишь первые минут 15. Потом Лиза поняла, что все идет наилучшим образом, вопросы как раз ей под стать. В конце наступил ее черед задавать вопросы.

"Мои ребята отлично покрывают все тестами. В них я уверен. Все сильные, самодостаточные. Думаю, мы отлично сработаемся и не будем друг другу мешать", - Team Lead разработчиков отвечал быстро, четко, глядя куда-то в сторону. Он говорил еще что-то, но кажется, фраза "Мы не будем друг другу мешать" зависла в голове Лизы на повторе.

Через два часа, она уже сидела в другом офисе, на втором собеседовании. Некоторые вопросы казались Лизе странными, но в целом все снова проходило ровно и спокойно. И снова Лиза попросила рассказать о команде. Слово друг за другом брали программисты, первый похвалился множеством сертификатов, второй готовностью брать самые сложные задачи, третий оказался душой компании. Последним снова высказался Team Lead. Молчаливый почти все собеседование, он и сейчас сказал немного, лишь слегка наклонился вперед и пообещал: "Ты всегда можешь прийти ко мне, и мы вместе будем внедрять лучшие решения".

Лиза приняла второе предложение о работе.

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

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

Подробнее..

Перевод Процесс это не продукт антиманифест методологии разработки ПО

19.06.2021 14:07:57 | Автор: admin

TLDR:

Антиманифест методологии разработки ПО

Процесс это не продукт

Руководство, а не менеджмент

Диалог, а не диктат


Вот и всё, остальное вы можете додумать сами, но если хотите, продолжайте чтение.

Процесс это не продукт


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

Если встретишь Будду на дороге убей его!

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

Не нужно так думать, они никуда не денутся.

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

Если можешь делать, то делай. Если не можешь, то управляй.

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

Руководство, а не менеджмент


И это приводит нас к следующему пункту манифеста: к лидерству. Знаете, такому настоящему руководству. Ты приходишь и показываешь путь вперёд. Лично каждому, чётко, по одному программисту за раз, и не только то, что они должны знать, но и спринты с use cases. Нужно иметь достаточно технических возможностей, чтобы обучать, готовить и мотивировать. И учиться самому. Сообщать всем, вплоть до уборщиков, куда и зачем мы движемся. Не один раз, а постоянно. Организации, которые будут это делать, окажутся самоуправляемыми. Почему? Потому что люди (даже программисты) умны. Если даёшь им информацию и полномочия, они думают, правильно расставляют приоритеты, не ругаются из-за смены целей и не особо нуждаются в менеджменте. Если сделать всё правильно, то окажется, что вы следуете за коллективом, а не ведёте вперёд, потому что культура команды становится больше, чем любой из её участников.

Диалог, а не диктат


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

Если всё это заставило вас ощутить неудобство, то это хорошо. Для того и написана эта статья.

P.S.: Никакой Jira.



На правах рекламы


Многие клиенты уже оценили преимущества серверов от Вдсины.
Мы предлагаем выделенные и виртуальные серверы. Максимальная конфигурация позволит реализовать практически любую идею 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Закажите и вы!

Подписывайтесь на наш чат в Telegram.

Подробнее..

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

04.06.2021 08:06:10 | Автор: admin

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

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

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

Содержание.

Что изучить еще до выхода на работу

Блог Уилла Ларсона

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

Книга Первые 90 дней Майкла Уоткинса

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

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

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

  • The rush to "show value" поясняет, как не наломать дров в стремлении быстро показать результат.

  • Your first 90 days as CTO or VP Engineering статья для лидеров уровнем выше, но полезна как карта куда направить внимание в первую очередь.

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

На старте. Собираем контекст и ожидания

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

Ниже я опишу, как на старте собирал контекст и устанавливал нужные коммуникации.

Сразу зарезервируйте время на обучение

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

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

Если мы не следим за балансом обязательств и копим незавершенку, то мы становимся все больше должны. Спираль может закрутиться до состояния, когда без нас уже ничего не может быть сделано, и мы вынуждены крутиться, как белка в колесе, чтобы поддержать хотя бы текущие обязательства. Еще это печальное состояние известно как bus factor = 1.

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

Понаблюдайте, как идет работа в компании

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

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

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

Daily sync с командой

Классический stand up meeting. Здесь я понял текущие боли проекта, настроение команды, кто в чем профи, есть ли тлеющие или явные конфликты.

Также этот митинг отличное время, чтобы легализовать себя в команде. Расскажите о своем прошлом опыте, чем вы увлекаетесь в жизни, как планируете действовать.Например, я рассказал, что не намерен крушить и строить заново, что сначала буду просто наблюдать. Что постепенно поговорю с каждым на 1-to-1, но только когда наберусь контекста, чтобы разговор был предметным.

Lead sync

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

Статус-митинг с PM и вице-президентом

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

Meet & Greet

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

Хорошо. Мы понаблюдали, изначальное представление о происходящем составили. Что дальше?

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

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

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

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

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

1-to-1 с PM проекта

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

  • Вы оба не сделали что-то, ожидая, что это сделает другой.

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

Список вопросов, с которыми я пришел на встречу с PM.
  • Каков общий ландшафт проекта и ключевые ценности для бизнеса?

  • Какие главные боли бизнеса в связи с проектом? Над чем явно стоит поработать в первую очередь?

  • Какие компоненты системы критичны, и кто их стейкхолдер?

  • Могу ли я понаблюдать за работой конечных пользователей?

  • Какие у команды есть обряды? Синки, ретроспективы, планирование, backlog triage? Как проходят эти встречи, и есть ли замечания к их эффективности?

  • Почему выбрали именно kanban (scrum, lean, любую другую методологию)? Какие плюсы уже ощутили? Какие ожидали, но не получили?

  • Ключевые эпики, roadmap на год, интересы стейкхолдеров.

  • Какая сейчас температура в команде, на проекте, в отношениях со стейкхолдерами?

  • Какие с точки зрения PM планы по техдолгу, багам, внепроектным активностям?

  • Стоит ли нам общаться 1-to-1 регулярно или хватит рабочих встреч?

1-to-1 с непосредственным руководителем

Эту встречу мы провели в начале второй недели.

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

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

Список вопросов, которые я обсудил с руководителем:
  • Общий ландшафт проекта и его ценность для бизнеса.

  • Главные боли бизнеса в связи с проектом. Над чем нужно работать в первую очередь?

  • Как менялась динамика команды и ее отношения с бизнесом со сменой тимлидов в прошлом? Как давно это происходило?

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

  • Какие планы у компании на этот год и глобальные планы?

  • Какие трансформации хочется провести в компании?

  • Есть ли подводные камни, о которых мне нужно знать?

  • Есть ли элементы культуры, которые стоит убрать? Что, наоборот, нельзя трогать?

  • Есть ли избыточные митинги или просадки в коммуникациях?

  • Какие основные риски в адаптации лида снаружи на твой взгляд?

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

Также очень рекомендую статью Уилла Ларсона Partnering with your manager. Она поможет построить с руководителем продуктивные отношения, а не просто приносить ему проблемы, с которыми он должен будет вам помогать.

1-to-1 с каждым участником команды

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

В моем случае предстояло провести девять встреч, и на них ушло полтора месяца.

Вот советы по подготовке к 1-to-1:

  • Прочитайте (или перечитайте) раздел про 1-to-1 в Team Lead Road Map.

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

  • Записывайте любые положительные отзывы о коллегах. На 1-to-1 поделитесь с коллегой, что о нем говорит команда.

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

  • До общения с коллегой не читайте его HR-карточку и историю решения сложных вопросов. Фрейминг существует и это штука очень сильная. Даже если вам кого-то представили как low performer-а, сначала поговорите с ним лично и разберитесь с его мотивацией.

  • На первый 1-to-1 заложите часа два и оставьте свободным календарь после. Мало что будет хуже, чем в разгар личной беседы убежать на другой митинг.

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

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

Список вопросов, которые я задавал

Конечно, список неполный, поскольку каждый 1-to-1 включал ряд личных вопросов.

  • Хочешь ли что-то обсудить прежде, чем мы перейдем к моим вопросам?

  • Каким ты видишь общий ландшафт проекта, ключевые ценности для бизнеса?

  • В каких частях проекта ориентируешься отлично? В каких хотел бы подкачаться?

  • Чем бы хотел заниматься? Хотел бы забрать на себя целиком какое-то направление? Какого плана задачи интересны (например, менторство)?

  • Как по-твоему идут дела на проекте?

  • Какие главные боли проекта?

  • Есть ли что-то, что мешает в работе лично тебе?

  • С кем тяжело работать в команде? А с кем хотел бы работать чаще?

  • Опиши идеального следующего кандидата в нашу команду?

  • Какие самые большие и интересные штуки стоит сделать? Что нужно сделать уже в этом году?

  • Есть ли у тебя долгосрочное видение себя? Хочешь составить план роста вместе? Что изменить, чтобы работа больше способствовала твоим целям?

  • Восхищаешься ли ты кем-то в компании?

  • Как чувствуешь себя на удаленке?

  • Что можно поменять в митингах?

  • Чувствуешь ли ты перегруз? Недогруз?

  • Что ты думаешь о фидбеке и его количестве? Как часто будем проводить 1-to-1 в будущем?

  • Хочешь ли что-то узнать обо мне?

  • Как настроение после беседы?

Итог по проведенным 1-to-1

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

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

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

Что полезного сделать, пока вы собираете контекст

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

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

Запишите, как проходил ваш найм

Комфортны ли были интервалы между собеседованиями и их количество? Было ли по ходу собеседований понятно, какой и когда следующий шаг? Получили ли вы оффер в виде красивого брендированного письма или это был просто неформатированный текст? Легко ли было найти офис и кабинет HR в первый день?

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

Запишите, как проходили первые дни в компании

Был ли у вас buddy? Достаточно ли было информации о компании на старте? Может, слишком много информации, и голова пухла? Как быстро вы получили технику? Был ли полезен корпоративный мерч, который вам выдали в первый день? Запишите все, за что зацепился ваш мозг, каждую мелочь.

Моя адаптация была очень комфортной, но через три недели я отправил коллегам из HR список из 30 небольших идей. Большинство они воплотили в жизнь, а позже, на Новый Год, подарили мне крутой рюкзак :)

Автоматизируйте/задокументируйте первые шаги на проекте

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

Составьте видимый план себя как лидера

Я решил сделать это в виде mindmap в miro, который базируется на Team Lead Road Map, но дополнен следующими моментами:

  • Моим опытом тимлида и пониманием, что важно в этой роли.

  • Ссылками на любимые статьи, курсы, книги.

  • Ссылками на документы и инструкции компании, релевантные роли тимлида.

  • Какие обязанности я забрал с предыдущего лида, а что еще предстоит забрать.

  • Какие из лидерских активностей я делегировал.

  • Какие активности относятся к категории muda, и я их постепенно истребляю.

Далее я поделился этим mindmap со всеми тимлидами, с нашим тим-коучем (да, у нас есть такой человек) и с вице-президентом. Также я делюсь им со всеми, кому интересна прокачка в тимлида, как инструкцией: что есть тимлид, что можно прокачать и где взять информацию для прокачки.

Приступаем к действиям

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

Это уже хорошие ориентиры для дальнейших действий. Вот еще парочка:

  • Статья Work on what matters поможет определить, куда направить свои усилия после того, как вы снимете все низко висящие фрукты. Как избежать жевания чипсов, то есть выполнения легкой и видимой, но не особо полезной работы.

  • Статья Good process is evolved, not designed в паре со статьей Managing technical quality in a codebase помогают постепенно вывести оптимальный процесс для команды и проекта, вместо декларирования с завтрашнего дня мы Agile и затевания революций.

И еще один совет. Чтобы помочь самому себе в будущем, систематизируйте весь получаемый сейчас опыт. Записывайте, что сработало, а что нет. Как вы внедряли изменения, с каким сопротивлением сталкивались. Например, можно вести brag document. Вот чем он будет полезен:

  • Систематизация полученного опыта

  • Если вдруг загрустили перечитаете и вспомните, сколько всего вы уже сделали

  • Можно найти темы для статей или докладов из своего же опыта - эта статья так и родилась.

  • Поможет при пересмотре зарплаты это готовый список ваших достижений

  • Поможет в подготовке резюме в следующий раз

В общем, практика полезная и непыльная.

А мы переходим к списку того, что я делал в первые месяцы.

Станьте клеем

Метафора с клеем, на мой взгляд, очень удачна и выражает собой 90% ценности лидера в команде и компании. Очень рекомендую посмотреть доклад Tanya Reilly на эту тему. Здесь же приведу примеры того, что можно и нужно склеить, придя в новую команду.

Склейте развалившиеся коммуникации

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

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

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

Сформулируйте единое понимание, зачем существует ваш проект

На каждом 1-to-1 я задавал один и тот же вопрос: Каков общий ландшафт проекта и ключевые ценности для бизнеса?. И я получил очень разные ответы.

Позже мы с командой сформулировали нашу ценность следующим образом:

Мы поставляем данные для принятия стратегических решений, поэтому наши данные должны быть абсолютно корректны, и система должна работать 24x7, чтобы избежать потерь. Сейчас с этой формулировкой знакомы все: ребята в команде, кандидаты на собеседованиях, даже CEO.

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

Отдайте процедурные долги

Тут примеры простые:

  • Согласуйте закупки железа или лицензий, которые давно нужны.

  • Обновите зарплаты тем, кому их давно не обновляли.

  • Согласуйте найм специалистов, которых не хватает в команде.

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

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

Выгоните призраков

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

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

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

Нам нужно лучше оценивать задачи

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

Если у вас не аутсорс и не fixed price проекты, попробуйте понять: а бизнесу вообще нужны точные оценки в часах? По моим наблюдениям, чаще нужно четкое понимание как идут дела сейчас, примерные сроки и понимание следующих шагов. Говоря проще, бизнесу нужна уверенность, что вы делаете то, что надо. Чтобы дать такую уверенность, нужны не высеченные в камне оценки, а постоянная коммуникация и выравнивание ожиданий если обстоятельства изменились. И бизнес отлично понимает, что обстоятельства просто не могут не меняться.

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

Бизнес не дает нам заниматься техдолгом, мы постоянно загружены задачами

Еще один классический призрак.

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

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

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

Определив наш WIP limit и показав его топ-менеджменту, я получил очень прямой и честный ответ Вы сами следите за своей нагрузкой. И вы не можете, а должны заниматься техническим долгом. Довод про перегрузку бизнес-задачами это просто нелепая отмазка. Если задач больше, чем вы можете сделать за раз, просто сообщайте об этом, и будем договариваться.

Так мы изгнали призрака бизнес плохой, и не дает нам делать работу хорошо.

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

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

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

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

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

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

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

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

Создайте общедоступные артефакты

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

Проект с высоты птичьего полета

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

Высокоуровневая архитектура проекта

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

Хорошую помощь в построении понятных и простых диаграмм может оказать нотация C4 Model, статья Thinking Like An Architect Part 5 и опыт в прохождении system design interview.

Технический роадмап проекта

По сути это временная шкала, отражающая что мы уже сделали, что в фокусе прямо сейчас, что планируем следующим шагом. Отдельным "облаком" - что будем делать дальше, но еще не проработали в деталях (unshaped).Мы не планируем дальше пары шагов вперем, не тратим время на декомпозицю и проработку архитектуры далекого будущего - это наша реализация принципа defer commitment. Засчет этого мы всегда сфокусированы на том, что делаем сейчас и действительно заканчиваем большие задачи, а не попеременно хватаем и бросаем самые горячие картошки.

Визуализация стратегических задач (эпиков)

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

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

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

Визуализация загрузки команды

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

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

  • Зеленый задачи долгосрочного технического развития. Снижение/предотвращение рисков, снижение operational costs, прокачка observability, testability и прочих ...ility

  • Желтый бизнес-задачи со стандартным приоритетом.

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

  • Красный авария, например, падение на проде. Мы не берем ничего, пока не разберемся с текущей ситуацией.

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

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

Что шло не по плану

Я все еще не пишу код

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

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

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

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

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

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

  • Делегируйте. Например, найм, онбординг, коммуникации со стейкхолдерами. Многое из того, что для вас рутина, для вашего коллеги будет точкой роста.

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

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

Да, это был момент настоящей паники

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

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

  • Джедайские техники Максима Дорофеева. Эту книгу я читал и раньше, но перечитать оказалось совсем не лишним.

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

  • Getting Things Done Дэвида Аллена. Еще одна книга, чтение которой я откладывал несколько лет. Исчерпывающее, хотя и сухое, руководство о том, как быть готовым к любой нагрузке. Вероятно, большинству система покажется слишком изощренной, но эта книга больше всего помогла справиться с нагрузкой. А со временем некоторые куски этой системы начали отваливаться сами собой, когда наплыв задач уменьшился. Некоторые практики становятся ненужными, когда вместо вороха дел у вас появляется долгосрочный горизонт и понимание, что важно. Эта книга помогает их найти.

  • То, как мы работаем не работает Тони Шварца. Книга про базовую гигиену труда и отдыха. Рекомендую прочитать ее всем, кто чувствует перегруз на работе и всем, у кого есть подчиненные.

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

Выводы

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

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

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

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

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

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

Подробнее..

Зачем тимлиду участвовать в подборе? Потому что ошибки найма упадут на него

09.06.2021 08:18:01 | Автор: admin

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

Про ошибку найма и ответственность

Что я понял на своем опыте: ошибка в найме это большой урон для компании и команды.

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

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

Для себя я это формулирую так: ответственный за подбор я, а рекрутер это мои руки в найме.

Когда рекрутер пинает тимлида и команду разработки это нормально

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

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

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

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

В результате сели за круглый стол: я, команда, рекрутер. И нарисовали схему:

  • как идет процесс

  • кто за что отвечает

  • какие максимальные сроки у нас заложены под каждый этап


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

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

А еще от зависаний нас спасает сервис из экосистемы hh.ru облачная CRM для рекрутмента Talantix. В ней можно прописать сроки под каждый этап воронки, и, если кандидат начинает подвисать, система сама напомнит. Это удобно не только разработчикам, рекрутер тоже доволен ведь у него куча задач, и иногда можно в суматохе забыть нас дернуть. А тут CRM сама подсказывает, освобождая от части рутины.

Кандидаты у нас долго не залеживаются, поэтому приложил скриншот из соседнего отдела:

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

Выбрасываем все лишнее

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

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

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

У рекрутеров в ходу есть такой мем;)

Заявка на подбор и текст вакансии это не одно и то же

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

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

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

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

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

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

История из жизни Как мы искали мидл-разработчика

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

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

Идеальные вопросы для интервью какие они?

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

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

История из жизни Как мы проворонили хорошего кандидата

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

Лайфхаки

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

Вот несколько наших секретов:

  • У нас есть общий чат, где прямо во время интервью можно написать Мне кандидат нравится, давайте еще вот это спросим.

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

  • Кандидату по результатам отвечаем не сразу, а на следующий день, чтобы можно было поспать со своим выбором.

  • Попробуйте провести ретроспективу по процессу найма.

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

Вместо заключения

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

Подробнее..

Категории

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

© 2006-2021, personeltest.ru