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

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

Профессия СТО

29.12.2020 10:06:55 | Автор: admin

Недавно наш СТО Евгений Россинский пообщался с ведущими подкаста Подлодка про роль СТО. По мотивам этого общения мы подготовили две статьи с основными вопросами о СТО как им стать и каково им быть, как его найти и сколько это стоит.

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

Е.Р.: Зависит от компании. В разработке ПО это будет одна история, в компании, которая сильнее связана с оффлайновым бизнесом другая. Там будет больше логистики и бэк-офиса, кассовые чеки, кассовые аппараты - и всё это должно работать вместе. А если глобально, СТО отвечает за стратегию технического и технологического развития компании и следит, чтобы все шестеренки крутились так, как это нужно бизнесу.

А в чем отличие CTO от CIO?

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

А может ли СТО вырасти вместе с компанией? Или когда компания переходит на новый уровень зрелости, ей будет лучше и логичнее найти СТО, который умеет управлять компаниями такого масштаба?

Резкий переход, конечно, будет очень сложный и болезненный для компании. Я не исключаю, что есть люди, которые настолько гениальны, что в состоянии быстро адаптироваться под резко изменившийся масштаб бизнеса, но, как правило, если ты не растешь плавно, у тебя не хватает времени понять, как работать по-другому. В быстрый рост я не верю. Я рос последовательно, и элементы консалтинга, которыми я развлекаюсь последние 6-7 лет, позволяют мне получать экспертизу в т.ч. за пределами компании, чтобы понимать, а как еще бывает. При этом мой путь к СТО был через CEO на протяжении 7 лет я был генеральным директором, но при этом душа рвалась от того, как отстроить подушку безопасности по зарплатам, к тому, чтобы заниматься проектированием. И хотя это мне удавалось, возвращаться назад и снова руководить всем, кроме разработки и технологий, не очень бы хотелось.

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

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

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

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

Есть вопросы, которые касаются драматической перестройки архитектуры как с точки зрения бизнес-логики, так и со стороны технических решений таких задач 3-5 в каждом квартале. В них я сижу по уши - настраиваю себе систему уведомлений по тикетам, делаю специальные синки, если нужно, создаю временные микро-, а где-то и макро-команды. Бывают задачи, которые ломают флоу компании. Нам надо было за месяц запустить спортивные трансляции, мы не делали этого раньше. Есть месяц, через месяц футболисты начинают пинать мяч, уже все оплачено, контракт стартует. Хочешь-не хочешь, надо успеть. У всех команд свои дедлайны, свои бэклоги с протухшим техдолгом, нехваткой ресурсов QA А тебе надо запуститься через месяц. И если тут ты говоришь: Ну, ребята, давайте договоримся, - это не работает. Наступило военное положение. Надо стараться, чтобы оно не наступало каждые три минуты, но если оно наступает - а пару раз в году такое случается - крокодилы начинают низенько, но летать.

Также у нас создана специальная система синков и демонстраций, чтобы можно было в любой момент времени подключиться к информационному потоку и понять, что происходит в компании здесь я уже выступаю в роли CIO. Например, по пятницам у нас есть так называемый Product Owner Sync. Примерно 20 команд из 26 рассказывают о самом важном, что произошло у них за неделю - мы научились укладывать эту встречу в 40 минут . Кроме того, важная потребность любого бизнеса - знать и уметь быстро находить информацию о предыдущих факапах и неудачах. Если кто-то из самоорганизующихся команд бежит в ту сторону, где уже похоронено несколько десятков, сотен или тысяч человекочасов, нужно вовремя сказать: Ребята, там рыбы нет, мы туда ходили много раз, вот эти могилы.

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

История с планированием и история с целеполаганием очень интересная. Пару лет назад я понял, что надо сделать процесс целеполагания внутри компании прозрачным, чтобы и самому понимать лучше. По сути это кусок тайм-менеджмента СТО. Я послушал доклад Егора Толстого про OKR в Avito, написал ему: Приди, пожалуйста, к нам в гости и расскажи правду. Егор, надо отдать ему должное, сказал: Да, конечно, приду. Он пришёл, рассказал правду и мы начали внедрять эту историю, которая мне помогает стратегически думать и это половина ответа на твой вопрос. А другая половина - ты убегаешь от всех людей, выключаешь мессенджеры и пытаешься сформировать свое мнение относительно того, что происходит вокруг. Потом начинаешь стучать этими мыслями во всех своих ребят. Это один паттерн. Другой паттерн, когда ты говоришь: Друзья, давайте, каждый из вас подумает, и мы пока не будем делиться мыслями, а обменяемся ими через недельку. В итоге все рассказывают, что у них болит. Ты думаешь: Блин, а я об этой хрени даже не думал. СТО - это не гений, который знает, куда вести компанию. Это человек, который в состоянии оценить те или иные решения. Часть придумывает он сам, но большую часть придумывает его команда. Это оркестратор, это кубернетес командного управления.

Есть ли СТО, у которых всё хорошо с work-life balance?

Я не очень верю в то, что человек говорит: Когда я выхожу с работы, я всё забываю, я обнулился. Я не знаю людей, у которых это так работает. Значит, им не интересно то, чем они занимаются. Да, можно сместить куда-то акцент, например, завести детей дети оттягивают на себя ресурс сами. Это прекрасные стейкхолдеры и продактоунеры твоего времени. Мне кажется, что у всех примерно одинаковая проблема: число задач всегда превышает число твоих возможностей. Так или иначе, СТО должен быть стратегом, мечтателем и смотреть вперед. Но чтобы смотреть вперед, нужно хорошо понимать, где ты находишься сейчас, и любить то, что ты делаешь, чтобы толкать это вперед и заряжать людей, которые рядом с тобой, тем, что интересно. Любое направление, особенно то, что касается информационных технологий, это довольно интересная история. Везде есть свой рок-н-ролл. Даже в такой прекрасной области знания как 1С, который почему-то в среде разработчиков считается странным направлением, есть своя романтика и драйв. Думаю, что для того, чтобы найти баланс между работой и чем-то личным, ты должен любить и то, и другое. А дальше оно всё естественным образом сформируется.

Любовь к делу понятно, первое, без этого фундамента дальше что-то строить будет сложно. Но каким образом СТО наращивает экспертизу?

Власть никто не даёт. Если кто-то выдал тебе власть, то, скорее всего, ты будешь хреновым управленцем. Власть берут сами. У меня всегда было шило в заднице. Я в институте стал старостой, всегда был активным, всегда мне было что-то нужно. Я понимал, что люди сами ничего не организуют, сейчас я их организую. Те, кто спрашивает: Ой, а как мне расти в сторону СТО? или Как мне стать тимлидом? хуже растут в управлении. Если у тебя возник этот вопрос, дружище, у меня для тебя плохие новости ты уже проиграл. Бывает обратная история - приходит человек с горящими глазами и говорит: У нас CI - говно! Смотрите, я придумал вот это, давайте? И все такие: О, тема! И вот ты возглавляешь этот путь хрен знает, куда. Ты достиг какой-то вехи, чего-то добился на пути управления людьми и ресурсами и далее тебе естественным образом захочется чего-то ещё. Я не очень верю в историю, что если получить степень МВА, станешь шикарным управленцем - чувак, который будет просто наглым, может обойти тебя за счёт харизмы. Если ты не понимаешь, как тебе расти, значит, первую проблему управления ты не решил. Как ты будешь рассказывать другим людям, как расти? Как только ты становишься лидом или техническим директором, тебе нужно будет так или иначе курировать в том числе процесс непрерывного развития твоей команды.

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

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

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

Два раза в неделю синк с топ-менеджментом, раз в неделю Product Owner Sync со всеми командами, где-то порядка 7-8 синхронизационных встреч с самыми важными командами и направлениями, начиная с эксплуатации и заканчивая разработкой. Раз в месяц или два раза в месяц у нас проходят Вопросы без правил, когда сотрудники или участники команд задают вопросы, от которых их сильно бомбит, и ты ходишь, собираешь ответы по другим департаментам чтобы разработчики понимали, что мы боремся с безысходностью, когда даже спросить не у кого. Например, ты сделал фичу, но А/В тест проиграл, её не раскатили, а ты её пилил полгода, и ты такой: Блин, ну почему? Тебе не объяснили, а тебя бомбит. Раз в квартал проходит OKR кухня, когда мы рассказываем, какие objective мы поставили себе и какие key result у нас есть по командам, оркестрация всего этого и подготовка нашими value-стримами, стейкхолдерами. Ещё мы периодически устраиваем различные лекции. Плюс история про годовое планирование, бюджетирование. История с деньгами очень тесно связана с жизнью СТО. Когда я был молодой, а деревья были зеленые, я думал, что технический директор думает про технологии - весело, классно. На самом деле часть твоей работы - это гребаные гугл-таблицы, в которых тебе нужно понять, а где тебе взять бюджет. Например, Сбербанк опять начал в железных бочках сжигать деньги на зарплаты людям, поэтому ты уже три месяца не можешь найти админа. Ты понимаешь, что рынок задрали, у тебя жёсткие рамки, а человек нужен. Надо либо выращивать, либо искать бюджет. И так или иначе тебе приходится оркестрировать историю с деньгами, если она не решается на локальном уровне команды.

О том, где ищут СТО, сколько это стоит и что происходит когда он приходит в компанию - читайте во второй части.

Подробнее..

Профессия СТО часть 2

13.01.2021 14:06:06 | Автор: admin

И: Что происходит, когда новый СТО приходит в компанию?

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

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

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

А как выглядит собеседование СТО?

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

А как тебя собеседуют?

Иногда говорят: Смотри, у нас есть такие-то проблемы, как бы ты их решал? Или говорят: Есть ли у тебя опыт того-то того-то? При этом верят на слово, потому что, как правило, тот, кто спрашивает об опыте, сам этим не занимался раньше. Когда тебя собеседует генеральный директор или директор по персоналу, они смотрят на твой уверенный тон, у них есть свои маркеры вранья. Ты должен побороть в себе синдром самозванца и сказать: А я вообще ничего!. В основном, мне кажется, им нужно понять, как ты будешь решать их проблемы, и можешь ли ты их решить. Все, кто собеседовал меня, хотели увидеть какую-то уверенность в завтрашнем дне. Что на этого парня можно спихнуть весь геморрой, который сейчас есть, который они сейчас тянут, потому что тянуть больше некому. Дальше ты плавно переходишь к своим вопросам, и, как мне кажется, твои вопросы говорят о тебе намного больше, чем те вопросы, которые тебе задают. Ещё есть история, когда люди просто тебя знают. Ты получаешь рекомендацию от кого-то из их команды, например: По технике он норм, посмотрите, на сколько он долбодятел, сможете ли вы с ним работать.

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

Поскольку я предпочитаю работать подолгу на одном месте, у меня есть довольно интересное мнение, которое касается и разработчиков, и СТО в первую очередь. Люди, которые прыгают из одной компании в другую, проработав по году, не отвечают за свои слова. Это значит, что те архитектурные решения, которые они сделали, проверяет кто-то другой. И они не получают того самого опыта, который нужен для жизни долгоиграющего сервиса. Ты устроился работать в компании, проработал там два месяца, написал какой-то сервис или сделал какую-нибудь фичу, а когда эта фича через 7-8 месяцев перешла в суровую эксплуатацию, ты увольняешься. Но кто будет отвечать за то, что эту хрень написал ты? У СТО ещё более длительный период. Ты принимаешь такие решения, за которые компания будет расплачиваться через несколько лет.

Есть какие-то вещи в твоей будничной рутине, которые, если бы можно было, ты бы вычеркнул из обязанностей СТО и никогда бы этим не занимался больше?

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

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

Вилки зарплат СТО примерно такие. Я не слышал о максимуме, но могу привести несколько примеров предложений, которые приходили мне. Я знаю, что сейчас зарплаты СТО начинаются примерно от 250 тысяч. Это мы говорим про компании не очень большого масштаба. В средней компании зарплата СТО сейчас, как мне кажется, около 450 тысяч. У гигантов побольше. Опять-таки, я смотрю по рынку по России. Если мы говорим про западные компании, история может отличаться, там роль СТО несколько более дорогостоящая. Но сейчас хорошие ценники болтаются около 700-800 тысяч. А дальше уже идут звёздные истории. Я знаю СТО с зарплатой в миллион, я знаю СТО с зарплатой полмиллиона, я знаю СТО с зарплатой 0,7 миллиона. И это всё довольно крупные проекты, которые на слуху.

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

Так совпадает, что люди выбиваются в сторону СТО примерно в районе кризиса среднего возраста или чуть-чуть пораньше - хотя я сильно до 30-ти начал заниматься управлением. Но по-хорошему, это просто жизненный вопрос: А что ты хочешь? Кто-то сильно упарывается по баблу. Идут в говнопроекты, где понятно, что то, что ты будешь разрабатывать, будешь разрабатывать в стол, и человек понимает, что оно никогда не полетит. Я знаю людей, которые в разные проекты ходят за деньгами. И когда они с помощью бонусных программ получают определенное value, они начинают не работать. Это один из путей. Второй из путей - когда ты переходишь в категорию бизнес-ангелов или инвесторов, людей, которые своим опытом и компетенцией помогают молодым компаниям пробиваться с технологической точки зрения. Тоже вполне себе интересная история. Этим славится определенное количество людей. То есть либо ты уходишь и делаешь свой стартап, либо ты просто помогаешь команде - за долю или ещё за что-то - которая тебе симпатична. Есть люди, которые продолжают переться от того, что они делают, и находить себе задачи и проекты, в которые они влюбляются. Я пока не разочаровался в том, чем я занимаюсь, и мне нравится то, что я делаю. Мне нравится заводить эти шестереночки и находить применение своим умениям. Плюс, есть два стандартных направления: вертикальный рост и горизонтальный рост. Ты можешь перепрыгнуть в компанию с большим штатом, с другими масштабами, ты можешь вырастить свою компанию - вариантов масса. А можешь пойти работать разработчиком, потому что, вы удивитесь, но в разных направлениях в большинстве случаев ценник заплат СТО не сильно отличается от зарплат разработчика или лида.

А что с опционами?

Не у всех есть опционы. Компаний, которые нормально целятся в опционную программу, немного. Тех, которые вообще без всяких опционов, больше 90%. Мы с вами привыкли смотреть на гигантов, которые выступают на конференциях, но рынок-то большой. Есть куча никому неизвестных компаний, которые делают офигенные вещи на хорошем уровне. Они не вкладываются в маркетинг, в бренд, они просто делают хорошо. Или работают на госорганы и не могут рассказать, что они делают хорошо. Но если закончить прошлую мысль, скажу так: ответственность СТО сильно больше, чем ответственность разработчика. Это то, о чем я говорил в начале - ты сам должен придумать, куда тебе расти. И если ты этого придумать не можешь, тебя ждёт очередной кризис, нервные срывы, психолог и синдром самозванца.

Подробнее..

Эволюция команды разработки

31.12.2020 14:09:18 | Автор: admin

Весной 2019 года меня пригласили руководить разработкой в небольшой стартап, занимающийся обработкой Big Data.

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

Команда разработки включала в себя 10 сотрудников: тимлид, front-end разработчики, back-end разработчики, системный администратор и DevOps. Стэк разработки: Python, PHP, JavaScript. Мои глобальные задачи были стандартны, но это не делало их простым. Я упорядочил их по порядку решения задач:

  1. Повысить качество и отказоустойчивость инфраструктуры

  2. Повысить квалификацию разработчиков

  3. Повысить качество ПО

Повышение качества и отказоустойчивости инфраструктуры

Проблема 1: Команда работала по старинке.Каждый разработчик сам управлял локальным окружением разработки. Это приводило ко всем знакомой ситуации при возникновении ошибок на productionе: у меня локально работало. Окружение должно быть единым для всех ваших окружений. С приходом контейнеризации (в частности, Dockerа) в массы, эта задача стала легко решаемой.

Решение: Контейнизируйте ваши приложения. Выберите единую ОС для вашего базового образа (на тот момент у нас был Ubuntu 18.04 LTS). Устанавливайте 3-rd party пакеты с точной версией, вплоть до хотфиксной. Пусть поддержкой занимаются системные админстраторы и DevOpsы, разработчикам делать там нечего.

Проблема 2: Много self-hosted сервисов, мало системных администраторов

Все проекты и их компоненты были на выделенных серверах, которые поддерживались двумя (а долгое время одним) системным администратором. Большая часть работы была рутинным админством: тут "подкрутить", там "отшлифовать".

Решение: Освободите руки системного администратора от рутинных задач насколько это возможно. Автоматизируйте свои процессы с помощью Terraform и Ansible. На уровне малого бизнеса/стартапа зачастую дешевле делегировать часть работы, чем нанять еще одного системного администратора. Возьмите managed СУБД и K8s, за одно решив таким образом такие проблемы как отказоустойчивость, масштабируемость и админством этой инфраструктуры.

Проблема 3: Вшитые в код ключи/пароли/сертификаты (секреты) от production сервисов

Решение: Внедрите систему хранения секретами, такой как Vault. Настройте политику доступа к этим данным. Перенесите все секреты из кода в хранилище и запрашивайте их при инициализации приложения.

Повышение квалификации разработчиков

На момент моего прихода в команде были в основном junior разработчики.

Проблема 1: Низкая квалификация разработчиков

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

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

Проблема 2: Каждый разработчик пишет код в своем стиле

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

Решение: Дирижируйте свою команду. Прививайте разработчиков к единому стилю написания кода. Используйте линтеры типа we-make-python-styleguide (сборник плагинов к flake8) для поддержания единого стиля.

Проблема 3: Отсутствие технологического развития

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

Решение: Много читайте и постоянно следите за новинками вашей области. Внедряйте и обучайте этому вашу команду. Вместе с ростом квалификации вашей команды растет и ваша.

Повысить качество ПО

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

Проблема 1: Плохо спроектированный код

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

Решение: Внедрите DDD и Twelve-Factor App.

Проблема 2: Классы, классы и еще раз классы по всюду

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

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

Проблема 3: Слишком сложные для понимания автотесты

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

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

Заключение

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

С наступающим, Новым годом!

Подробнее..

Как в MGA в 5 раз быстрее реализуют проекты при помощи GitLab

11.01.2021 12:12:41 | Автор: admin


Как в MGA в 5 раз быстрее реализуют проекты при помощи GitLab


Благодаря переходу на GitLab в MGA внедрили практики CI/CD, повысили качество ПО, создали процесс обмена знаниями и сэкономили средства.


Oбзор

В MGA перешли на GitLab с целью улучшения качества и сокращения сроков разработки с использованием автоматизированных процессов CI/CD.

Трудности

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

Pешение

GitLab EE

Преимущества

  • Автоматические сканеры кода в конвейере CI
  • Улучшенные возможности совместной работы
  • Повышение эффективности операционных процессов
  • Улучшение качества продуктов
  • Простота интегрирования

C 80 до 240 Увеличение объема проектов


10 В 10 раз больший коэффициент успешного выполнения, чем при ручном развертывании CD


80% Экономия времени при переходе на CD


Kлиент Разработчик корпоративного логического ПО


MGA разрабатывает, создает и внедряет компьютерные приложения для крупных и средних коммерческих и промышленных предприятий. Компания MGA, основанная в 1993 году, создала логическое программное обеспечение, которое использует преимущества реляционной базы данных (Oracle), работающей на операционной системе Linux. В 1999 году MGA создала подразделение аутсорсинга и начали предоставлять бухгалтерские услуги, кадровую поддержку и услуги по расчету заработной платы более чем 30 компаниям.

Tрудности Недостатки в совместной работе, поддержке и качестве кода


В MGA сами писали код и использовали Mercurial. Команда разработчиков протестировала бесплатные инструменты, которые позволяли проверять код и поддерживали CI и CD. Это оказалось сложным процессом, так как у программистов не было опыта в использовании подобных инструментов, а поддержка при их установке и применении не предоставлялась. У MGA возникли серьезные проблемы, поскольку Mercurial был слишком сложным, а у разработчиков не хватало опыта в использовании инструментов CI/CD.

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

Из-за невозможности совместной работы и отсутствия общего доступа к документации снижалось качество кода. Мы начали искать инструменты, которые позволяли бы нам просто осуществлять проверку кода и создавать политику утверждения для управления кодом. Вторым приоритетом было системное использование CI/CD с целью упростить работу и свести к минимуму штат администраторов, рассказывает главный ИТ-администратор Якуб Тадея.

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

Pешение Динамичный инструмент по выгодной цене


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

Тарифный план GitLab подходил MGA больше всего. Это стало важным фактором в принятии окончательного решения. Мы зарабатываем меньше, чем компании на Западе Мы искали решение, которое бы позволило размещать приложения на нашем сервере. Насколько мне известно, GitHub и прочие облачные решения не позволяют этого сделать. Их невозможно использовать локально, поясняет Тадея.

До начала использования GitLab программисты работали в небольших командах над мелкими проектами. Но по мере роста компании увеличивались объемы проектов и численность команд. Внедренные инструменты уже не справлялись с такими масштабами. Благодаря GitLab, создание наших проектов полностью изменилось, утверждает Тадея. Первоначально у нас не было больших ожиданий. Нам просто был нужен новый инструмент, который дает возможность создавать конвейер CI/CD и политику проверку кода. Большего мы не ждали. Однако, как выяснилось, GitLab может предложить намного больше. Постепенно мы начали экспериментировать с функциями, и нам понравилось.

Благодаря GitLab, команды смогли планировать дорожную карту ПО и устанавливать сроки окончания проектов. Мы начали планировать проекты, используя непрерывную интеграцию и развертывание. GitLab полностью изменил архитектуру нашего решения, говорит Тадея.
У CD как минимум в 10 раз больший коэффициент успешного выполнения, чем у развертывания вручную. У нас есть проекты, где ни разу не подвело автоматическое развертывание. Якуб Тадея, Главный ИТ-администратор

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


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

До перехода на GitLab было 3 ИТ-администратора и 30 разработчиков. Теперь у нас более 60 разработчиков, которых легко обслуживают три ИТ-администратора, и много других серверов. Задержки больше не возникают, поскольку большая часть проблем больше не ложится на плечи ИТ-администраторов.

С начала использования GitLab количество проектов увеличилось с 80 до 240. В запущенных проектах все выполняется через CI и CD. По мере необходимости мы просто решаем проблемы и учим разработчиков пользоваться инструментами GitLab, поясняет Тадея. Теперь наша работа более эффективна, и мы можем уделять больше внимания коду, не отвлекаясь на простейшие задачи, которые можно автоматизировать.

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

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

Благодаря поддержке GitLab, MGA быстрее создает более качественные программы, улучшив процессы тестирования и проверки качества кода. ИТ-специалисты и команды разработчиков стали специалистами в области CI/CD и создают оптимизированные системы автоматизации, при этом сводя к минимуму потребности в ИТ-администрировании и повышая эффективность затрат.

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

Перевод Как НЕ сделать многопользовательскую игру в реальном времени за 30 дней

08.01.2021 12:15:36 | Автор: admin

Или как добиться большего на следующем вашем хакатоне


Некоторое время назад я принимал участие в ежегодном игровом мероприятии Itch.io Game Off 2020, участники которого за ноябрь делали игру на определённую тему. Тема этого года, Moonshot, привела к созданию более 500 амбициозных, в основном космических, игр, которые вы можете увидеть здесь.

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

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

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

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





Понимание требований проекта


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

Без особой причины мы решили попробовать свои силы в создании интерфейса с помощью Flutter, используя Flame, минималистичный движок для 2D-игр. Для нашей игры этот выбор казался разумным. Серверная часть, однако, окажется сложнее. Многопользовательские онлайн-игры заведомо сложны в разработке, и компонент реального времени, который нам хотелось воплотить в жизнь, только усугубил бы эту сложность.

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


Тест синхронизации данных с WebSocket

Не упускайте из виду главную задачу


К сожалению, то, что должно было закончиться за несколько дней, продлилось до середины ноября. Хотя настроить и запустить Firebase было непросто, главным пожирателем времени было кое-что другое отвлечение внимания. На реализацию того, что вы видите на гифке выше, у нас ушло несколько дней. Из этого мы извлекли урок: бессерверный подход Firebase с Cloud Functions и Firestore (один из двух вариантов облачной базы данных) хотя и полезен во многих ситуациях, но не сможет удовлетворить требованиям к игре в реальном времени, которую мы предполагали создать.

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

Не экономьте на исследованиях


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

Хотя мы пользовались многими инструментами, которые предлагал Flame, мы в конечном счёте реализовали многое самостоятельно. Не потому, что реализация во Flame была неадекватной, а просто потому, что мы не знали о её существовании! Стремясь приступить к работе, мы быстро прошли через самый важный этап этап исследования. В результате мы создали множество компонентов с нуля, не зная, что они добавлялись инструкцией import.

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

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

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

Знайте свой инструмент


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

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



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

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

Рассмотрите подход к работе слоями


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

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


План разработки высокоуровневых функций для Bad Asstronauts с 7 уровнями сложности

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

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

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

Не откусывайте больше, чем можете прожевать


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

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

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

image



Подробнее..

Я единственный из 1400, или самый крутой рекрутинг, что я проходил

25.12.2020 02:10:45 | Автор: admin

Я уже лет 10 пишу код на питоне, и последние 2.5 года стабильно работал на американскую компанию. Наверно, многим знакома история, когда ты кодишь-кодишь, вроде всё неплохо, и внезапно ты - самый знающий и опытный в команде и добро пожаловать в тим лиды. Астрологи объявили неделю менеджмента, количество кода снизилось на 100%.

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


Как это бывает

Прежде чем холиварить на тему "как надо", давайте вместе согласимся, как не надо.

HR

В более-менее крупных компаниях есть HR - это скрипты, которые по ключевым словам находят людей в LinkedIn и пишут им шаблонные сообщения (и даже способны вести диалог на уровне яндекс.алисы: знают захардкоженныеи ответы, по всему остальному отсылают куда-нибудь). Очень часто компаниям лень писать такие скрипты и они нанимают миловидных девушек для этого, но блин, ребята, за один вечер можно написать неплохого HR, который будет донимать людей в соцсетях и писать описание вакансии в телеграме - так ещё и работать будет 24/7, и стоить дешевле. Рекомендую.

Так как я искал работу, то я осмелился включить в LI опцию "open to job offers" - и меня завалило предложениями, бессмысленными и беспощадными. Шутят, что LinkedIn - это сайт знакомств для айтишников, где последние постоянно отшивают девушек. В какой-то момент я задолбался тратить время на вводную часть и хотел хакнуть систему, говоря, чтобы они сразу дали мне самое сложное тестовое задание, и если я справлюсь, то имеет смысл говорить дальше - но меня редиректили на стадию "нужно сначала познакомиться друг с другом".

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

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

Интервью

На моей старой работе мы интервьюировали многих - начиналось с того, что мой босс рассказывал минут 10 про компанию, потом мы минут 15 слушали, какой кандидат классный и что он умеет, потом 5 минут смотрели на него во время live coding, и всё было решено. Нет, мы давали кандидатам время, чтобы они закончили задание, но вообще-то уже после 5 минут было понятно, нравятся нам его скиллы или нет, и получается, что только эти минуты были по-настоящему важны. А мы просто теряли время.

Я был и с другой стороны баррикад. Однажды я потратил целый час на общение с hr из епама - блин, мы уже разве что только не поженились, мы уже обговорили график работы и на каких условиях моя тушка будет релоцироваться. Через пару дней я завалил их собеседование. Итого: два человека продолбили по часу, обсуждая то, чего не будет; два человека продолбили по часу, чтобы понять, что один не подходит. 4 часа просто в никуда. В денежном эквиваленте мы все потратили тысяч 10 наверно, это прикольно осознавать.

Знаете, какой должен был быть первый вопрос от этой компании? Вот такой сниппет на питоне:

a = 400b = 400id(a) == id(b)  # true or false?

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

Оказывается, интервью можно сократить процентов на 90% и не потерять ничего, просто поменяв порядок вопросов.

Независимость умений

У нас был случай, когда чел успешно прошёл интервью - сделал 2 небольших задания, не идеально, но показал, что может быстро учиться, ну и решение работало в конце концов. Мы его наняли. Потом мы узнали, что он не очень в гите, не умел отлаживать, код был так себе, а ide была atom, и он, например, не мог jump to definition или search class например. Про статический анализ кода вообще молчу.

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

Интервью должно в идеале покрыть всё, что вы ожидаете от кандидата. Нельзя ждать, что если A, то B - проверяйте и A, и B.

Background

Люди продают себя, и поэтому CV - это как Инстаграм: люди добавляют туда только лучше, а всё что "не очень", деликатно умалчивают.

Как-то у нас было собеседование с мужчиной - лет 40, почасовая оплата такая, что я шёл на интервью, как будто это он меня будет собеседовать, а не я его. Как он классно говорил про свои проекты! Я был просто уверен, что он крут, залетит к нам на проект, всё наконец заработает, меня вышвырнут как слабое звено и я останусь ни с чем, буду плакать и искать работу. Когда мы дали ему тестовое задание, он его зафейлил, от слова "совсем". Я прям не верил глазам, там всего-то пробежать по json и вытащить определённые значения - но он был слишком крут для этого. И тут я понял: CV, описание опыта, всякие там профили на сайтах - это всё ничто, это только bias, который зачастую ошибочен, потому что это одна сторона медали - лучшая. Мы все не без недостатков - но как работодатель, я хочу знать все стороны - с некоторыми я могу мириться, с некоторыми нет.

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

Ребята, я нашёл

Да, я нашёл ту компанию, которая возвела рекрутинг в абсолют. Они ушли от стандартной "HR, Interview, Test task" схемы, и сделали рекрутинг постоянно изменяющимся процессом, когда собирается статистика и на её основе части процесса добавляются/изменяются/удаляются. Когда я устраивался в эту компанию, я проходил через пятую версию процесса отбора кандидатов. Сейчас мы работаем над седьмой.

Далее я расскажу про все шаги, через которые я прошёл. Вакансия: senior python developer (django, remote only) - это важно, потому что иная вакансия привела бы к совершенно другим шагам.

Итак, как это выглядит.

Без HR

Тут нет HR. Зачем? Мы постим объявление на разных площадках и имеем постоянный поток кандидатов. Есть подозрение, что это даже дешевле HR.

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

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

Самый тупой фильтр на свете

Представьте, что у вас есть постоянный поток кандидатов. Интервью с каждым - самоубийство. Разбор тестового задания каждого - куча времени. Что, если я скажу, что есть способ отсечь 80% неподходящих кандидатов вообще без телодвижений?

Первый вопрос кандидату - его стаж. Это не какое-то число из головы - напротив, мы взяли статистику и нашли такое число N, что кандидаты со стажем меньше N лет никогда не проходили все этапы. То есть, согласно всем нашим наблюдениям, это минимальный порог для успешного прохождения собеседования. Поэтому мы запилили формочку, где кандидат тыкает своё число и либо проходит дальше, либо мы вежливо отказываем. Зачем это? Каждый этап отбора стоит компании всё больше и больше (и по деньгам, и по ресурсам), и этот маленький вопрос значительно снижает нагрузку.

Пиши код

Кто-то тут на Хабре писал, что тестовые задания фу-фу-фу, но я-то знаю, что задания на кодинг как старый добрый кольт: уравнивают всех. Много опыта, мало опыта, красивое CV или его отсутствие - покажите мне свой код, и я скажу, кто вы. Сколько раз было: на словах ты Лев Толстой, а на деле у вас тут мешок эксепшнов. Не знаю, если кто-то тут нанимает разрабов без хоть какого-то кодинга - расскажите мне, как так-то?

У нас раньше был live coding, но есть огромные минусы:

1) это стресс для кандидатов - никто не любит, когда рассматривают и оценивают, как он кодит;

2) он не показывает реальные способности программиста в обычной среде - обычно человек кодит в спокойной обстановке, попивая кофе, а тут он висит на звонке и должен что-то сообразить - я сам, например, люблю live coding, но тупею процентов на 50;

3) live coding требует, чтобы кто-то из команды на нём присутствовал.

Итак, задание на написание кода нужно, но только не live coding и без человеческого участия. Как вы, наверно, догадались, есть много сервисов, которые позволяют тестировать кандидатов в автоматическом режиме. Мы используем один из таких, там есть окно для ввода кода и можно запускать программы на питоне (и на других языках тоже). Просто кидается ссылка на тест, а потом можно забрать результаты по API. Наши задания простые, на их решение хватает и 15 минут, но мы даём 1.5 часа. На некоторые задания уходит менее 2 минут, так что это действительно простые вещи. Ну, например, инвертировать содержимое в маленьком файле, типа data[::-1], без подводных камней. Вы не поверите, но это отсекает 80% народа, серьёзно - хотя они претендуют на место senior python developer.

Тестируется всё, что требуется от кандидата

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

1) это последняя линия обороны перед участием человека в рекрутинге, то есть если человек прошёл этот этап, компания начинает тратить ресурсы на рекрутинг;

2) это задание, которое довольно хорошо отбирает сеньоров;

3) оно опять же полностью автоматическое.

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

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

Тестовое задание

Далее уже сложнее - тестовое задание. Кандидат ставит трекер и логгирует время, потраченное на решение задания. Оно тоже классное по нескольким причинам:

1) позволяет кандидату разобраться с трекером, который используется в компании,

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

3) мы оцениваем умение кандидата работать удалённо

4) задание "fuzzy" - сказано, что должно быть в итоге, но как это получить - кандидат решает сам; мы оцениваем, насколько кандидат умеет здраво мыслить и понимать требования клиентов

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

Да, это долгий процесс - может занимать 3 часа у кандидата. Как сделать, чтобы он не бросил эту затею? Мы заранее говорим, что все работы будут оценены вручную, и по каждой из них будет сделан детальный code review. И мы делаем, причём каждый такой ревью занимает в среднем 40 минут - но тем не менее мы не игнорируем ни одного кандидата. Это мотивирует, потому что даже если кандидата завернут, он точно будет знать, почему и над чем нужно работать.

Интервью

Вот тут уже случается разговор с СЕО компании. Это не интервью в классическом смысле - скорее знакомство и ответы на вопросы. На этом этапе никакого отсева :)

Пробный период

Далее кандидат попадает на пробный период.

Он прекрасен для кандидата, потому что

1) кандидату платят полную ставку, как если бы он уже полноценно работал,

2) кандидат считается полноценным членом команды (без всяких исключений) и имеет равный со всеми голос.

Этот же период ужасен для комании, потому что

1) компания может потратить в 5 раз больше заработанного кандидатом только на его сопровождение - то есть кандидат наработал на 40$, но все люди, задействованные в этом, потратили на это своё время на 200$.

Избыточные задания

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

1) опять же выявляют способности кандидата в некоторых специфических областях;

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

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

Некритичные задачи

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

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

К чему всё это

Заголовок не врёт - до меня компания забраковала 1400 кандидатов. Когда я это узнал, я почувствовал, что я самый классный парень на деревне - кто ещё может таким похвастаться? А потом подумал и понял, что нет. Не я самый классный, а рекрутинг.

У меня на прошлой работе есть чел, который мультитул - он круто пишет код, может настроить логгирование в cloudwatch, позвонить в какую-нибудь команию и договориться с ними о сотрудничестве, попутно тренируя какой-нибудь xgboost или spacy. Ещё у меня есть друг, который всё схватывает на лету и просто мозг - я себя рядом с ним чувствую мобильным процессором с низким энергопотреблением. Круче ли они меня? Совершенно точно. Прошли бы они всё, что я описал? Я сомневаюсь.

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

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

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

Подробнее..

10 полезных книг для менеджера и лидера в IT секторе

26.12.2020 20:23:24 | Автор: admin


Я работаю много лет в индустрии разработки программного обеспечения и последние несколько лет я активно вовлечен в консалтинг и pre-sales фазы. И я заметил, чтобы быть успешным лидером как для менеджера проектов, представляющего бизнес-сторону, так и для архитектора технического представителя необходимо совмещать в себе технические и лидерские качества.
Для меня наиболее полезным и эффективным источником обучения являются книги. И я бы хотел поделиться с вами топ 10, по моему мнению, книг полезных для начинающих и не только лидеров в разработке программного обеспечения. Эти книги помогут развить и улучшить лидерские качества необходимые в данной индустрии. Я не буду перечислять знаменитые менеджерские бестселлеры такие как Laws of Leadership или Good to Great. Я порекомендую более целевые книги, которые будут, несомненно, полезны именно лидерам в индустрии разработки программного обеспечения.
Название всех книг будут указаны на языке оригинала, но вы без труда сможете найти многие из них и в переводе.

Mythical Man-Month, The: Essays on Software Engineering




Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition

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

Death March




Death March (2nd Edition)

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

Consulting Outbreak: Manager and Software Architect Could be Friends




Consulting Outbreak: Manager and Software Architect Could be Friends

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

The Deadline: A Novel About Project Management




The Deadline: A Novel About Project Management

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

Waltzing With Bears: Managing Risk on Software Projects




Waltzing With Bears: Managing Risk on Software Projects

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

Herding Cats: A Primer for Programmers Who Lead Programmers




Herding Cats: A Primer for Programmers Who Lead Programmers

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

The Art of Project Management




The Art of Project Management (Theory in Practice (OReilly))

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

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity




The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (2nd Edition)

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

Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers




Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers

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

Inspired: How To Create Products Customers Love




Inspired: How To Create Products Customers Love

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

Настоящий металл как сплавить команды в горниле совместной разработки

28.12.2020 16:18:38 | Автор: admin

У нас было 2 проектных менеджера, 72 эксперта от производства, 33 высококлассных спеца из двух IT-команд, несколько десятков систем управления производством по всей стране, а еще, разработчики КРОК и Группы НЛМК прежде не работали вместе.

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

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

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

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

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

Нашими стараниями, к бумажным сертификатам добавились QR-кодыНашими стараниями, к бумажным сертификатам добавились QR-коды

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

Другое дело цифровой сертификат. Можно заверить его электронной подписью, добавить исчерпывающие характеристики товара и напечатать на каждой этикетке или бирке QR-код с уникальной ссылкой на все эти данные. А для проверки электронно-цифровой подписи существуют специальные общедоступные сервисы. В частности, подлинность ЭЦП не сложно проверить на портале Госуслуги.

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

Работа в тандеме

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

В НЛМК сложный IT-ландшафт на каждом заводе, в каждом цехе свой парк оборудования и связанные с ним MES (manufacturing execution system) системамы планирования и управления производством. Это десятки цеховых систем управления, которые работают в разных часовых поясах, предоставляют данные в разное время и в разных форматах, а также системы корпоративного класса (ERP, CRM и пр.)

Чтобы реализовать QR-кодирование продукции, нам нужно было найти общий язык с системами на четырех российских площадках Группы НЛМК: Новолипецком комбинате, НЛМК-Урал, НЛМК-метиз и НЛМК-Калуга.

Катанка, моталка, прокатка, бунт, швеллер и подмотка лишь некоторые термины и слова, которые вошли в мой словарь за время работы с НЛМК, Марина Зиновьева, аналитик проекта, КРОК.

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

Распределение зон ответственности в рамках проектаРаспределение зон ответственности в рамках проекта

В нашем случае часть команды со стороны Группы НЛМК отвечала за общее видение системы, архитектуру и архитектурный контроль, инфраструктуру. Они предоставили экспертизу по MES. DevOps, проектирование, планирование работы и собственно разработка были на стороне КРОК.

Для разработчиков КРОК это был первый масштабный проект в такой тесной связке с командой НЛМК. И что могло пойти не так?

Старт проекта

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

Они ожидали от партнера такой же погруженности. Поэтому для команды КРОК проект стартовал будто с места в карьер. Через несколько часов после окончания конкурса раздался звонок:

Добрый день! Присылайте план проекта.

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

Не спали ночь, но прислали.

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

Для НЛМК проект оказался так важен, что они провели собеседования с каждым членом нашей команды, Ярослав Репной, менеджер проекта, КРОК.

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

Пара коротких спринтов на практике доказала, что разработчики КРОК и Группы НЛМК могут продуктивно работать вместе. Появилось время, чтобы познакомиться с новыми коллегами и вникнуть в нюансы задачи.

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

Не у каждой IT-компании есть аналогичные решения. Как правило, приходится внедрять такие решения у заказчика самим. Это сильно ускорило нашу работу в ЕЦП все спроектировано, задумано и внедрено удобно. Спорить с НЛМК в части ЕЦП не приходилось вообще OpenShift, Kafka, S3 всё на месте, всё как мы любим.

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

Аджайл VS реальность

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

Проект состоит из семи этапов, так что мы разбили работу на параллельные потоки:

  1. тираж QR-кодирования сертификатов качества и готовой продукции на трех производственных площадках;

  2. разработка сервиса для утверждения сертификатов качества электронной подписью;

  3. разработка стартовых веб-страниц для экспортной продукции группы НЛМК;

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

  5. API для интеграции сервиса с информационными системами покупателей;

  6. разработка тартовой страницы для предоставления информации по продукции, маркируемой DataMatrix-кодами;

  7. разработка сервиса для автоматизации работы с несоответствиями готовой продукции (подача претензий по QR-кодам).

Фактически ребята ведут семь 7 потоков параллельно. Одну задачу разрабатывают, другую проектируют, третью выводят на демо, а по четвертой ждут результаты от зависимых систем, Ангелина Панарина, руководитель проекта, НЛМК-ИТ.

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

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

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

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

Распределенная команда

Со стороны КРОК в проекте участвовало 11 человек. Ядро команды Группы НЛМК состояло из 24 IT специалистов. Получилась гибкая и разносторонняя команда, но постепенно в проект оказалось вовлечено больше 100 сотрудников из других подразделений НЛМК: эксперты от производства, интеграторы MES, инженеры, специалисты и руководители по продажам и начальники цехов.

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

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

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

Вы мне про аджайл, а мне оборудование настраивать надо, инженер Группы НЛМК, пожелавший остаться неизвестным.

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

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

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

Сложности коммуникации

Участники объединенной команды были разбросаны от Минска до Иркутска. Даже не будь пандемии, собраться вместе мы бы не смогли. Так что в начале проекта Skype-конференции стали основным каналом связи. Календарь состоял из непрерывных встреч и обсуждений. Времени на разработку не оставалось.

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

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

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

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

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

Вместо заключения

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

Для нас КРОК близкие друзья, мы учимся у них гибкости и неформальному подходу к решению задач, Ангелина Панарина, руководитель проекта, НЛМК-ИТ.

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

Одни клиенты НЛМК уже пользуются сервисом и оценили его преимущества, другие пока знакомятся и разбираются, как наше решение упрощает их бизнес-процессы. Одним из следующих этапов развития QR-кодов будет полная интеграция с личным кабинетом клиента в онлайне, а также интеграция со складскими и учетными системами клиентов, Иван Говорухин, менеджер бизнес-решений, Группа НЛМК.

В ближайшем будущем клиенты Группы НЛМК на базе Единой Цифровой Платформы смогут мгновенно получать сертификаты качества, отслеживать поставки товаров, автоматически учитывать их при поступлении на склад при помощи API и быстро сообщать о дефектах продукции через личный кабинет на портале НЛМК.

Этот проект направлен на повышение удовлетворенности и создание максимально удобного сервиса для наших клиентов, партнеров и конечных потребителей продукции. Например, он позволяет нашим оптовым партнерам осуществлять упрощенную процедуру складского учета продукции, а также позволяет сделать прозрачным ее дальнейшую продажу, Борис Ашрафьян, начальник Управления Проектный офис, Группа НЛМК.

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

1. Выделите время на плавный старт

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

2. Убедитесь, что все одинаково хорошо понимают цели и задачи проекта

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

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

Главное создать vision of future, когда все понимают, осязаемо понимают, что мы собираемся делать, Игорь Кораблев, энтерпрайз-архитектор, НЛМК.

3. Изучите команду

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

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

4. Вовлекайте в совместную работу

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

5. Доверяйте друг другу

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

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

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

6. Держите руку на пульсе

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

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

7. Обучайте и обучайтесь

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

Мы научились ставить задачи друг другу и работать, как единое целое. Я вижу взаимный профессиональный рост разработчиков КРОК и НЛМК, Дмитрий Лаптев, технический менеджер, КРОК.

8. Создайте единое информационное пространство

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

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

9. Не пытайтесь решить проблемы на 100%

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

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

P.S. Если у вас остались вопросы, можете написать на ipopkov@croc.ru.

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

Подробнее..

У Вас проблемы с legacy значит, Вам повезло! Распил монолита на PHP

06.01.2021 06:14:44 | Автор: admin

Вступление

Меня часто просят рассказать о работе с legacy-монолитами. Про микросервисную архитектуру и переход на нее говорят много, но редко упоминают о том, что проекты приходят ней после многих лет роста с монолитным приложением. Учебники по решению проблем не пишут. Чтобы поменять архитектуру живого решения, надо пройти через несколько этапов. Автор работал с разными проектами - и с полноценным multitenancy service-oriented REST architecture в Oracle, и с огромным монолитом, в репозитории которого были коммиты за десять лет. Эта статья - о темной стороне, о legacy-коде, и практических решениях проблем с монолитными приложениями на PHP.

Причины появления legacy

Есть две основные причины появления legacy-кода.

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

Вторая - технический долг, который создается специально. Руководство сокращает срок разработки ПО за счет отказа от проектирования, автоматического тестирования или code review, одобряет сторонние библиотеки, которые не поддерживаются, а разработчики не документируют сложную логику. Это встречается повсеместно и не зависит от количества денег на счету компании. Не стоит ругать плохих начальников. У них есть весомые причины поступать именно так.

У продуктов есть жизненный цикл, период большого спроса на популярные товары длится три-четыре месяца. Все лучшее конкуренты скопируют и сделают еще лучше, поэтому компании вынуждены регулярно выпускать новинки. Чтобы поддерживать объем выручки, новые продукты и новые версии выпускают каждые несколько месяцев, так продажи нового цикла компенсируют снижение продаж по товарам в конце цикла. По три-четыре крупных релиза в год делают и Apple, и Marvel, и в Oracle на рынке enterprise SAAS тоже квартальный релизный цикл. При этом, рецепта успеха не существует. 97% стартапов выкидывают наработки по своему продукту, и пробуют делать что-то новое, прежде чем найдут такой продукт, который у них покупают. Поэтому затраты на разработку MVP в стартапах максимально сокращают.

У вас проблемы с легаси - значит, вам повезло!

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

Проблемы?

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

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

Что делать тем, кому повезло?

Начинать надо с тестирования

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

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

Обновление версии языка

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

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

Составить список проблемы совместимости с новой версией PHP помогут утилиты статического анализа.

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

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

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

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

Обновление версии платформы или языка в таком случае выполняется достаточно быстро. Автор был инициатором обновления PHP с 5-ой версии на 7-ую для приложения с очень большим объемом кода, и эта задача была успешно выполнена командой за три недели.

Переход от монолита к сервисной архитектуре

Иногда проекты вырастают. Продукты стали успешными на рынке, и регулярно выпускаются. По законам Лемана сложность ПО растёт, функциональное содержание расширяется, вместе с ними штат разработчиков и объем кода постоянно увеличиваются. Замена устаревшего ПО в бюджет разработки не закладывается, чтобы улучшить финансовые результаты, поэтому качество программ ухудшается. Размер git-репозитория может исчисляться гигабайтами. Постепенно скорость разработки уменьшается, и когда разработчики перестают успевать выпускать ПО для новых продуктов, монолит решают разделять.

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

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

Перенос кода в пакеты открывает ряд возможностей:

  • можно сократить размер репозитория приложения,

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

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

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

  • можно выпускать разные версии пакетов, и согласовать изменения API.

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

Разделение приложения на пакеты

Допустим, есть приложение на PHP, которое предоставляет клиентский API. Начинать любые изменения надо с процедур тестирования и релиза, которые включают план отката. Эти процедуры называют release, control, validation и DevOps. В активно развивающихся проектах тестирование и выкладка отработаны. В этом случае надо начинать разделять приложение с определения таких ограниченных контекстов, которые логично выделить в отдельные модули и сервисы.

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

Создание отдельного модуля - это цикл из пяти подзадач:

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

2. Определить API модуля - написать интерфейс, доступный приложению;

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

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

5. Заменить в коде приложения прямые обращения к старому коду на вызовы сервиса из нового модуля; Для решения этой задачи используется две технологии: IoC-контейнер и менеджер зависимостей.

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

Начать создавать пакеты можно в локальном каталоге, а для полноценной сборки и развертывания стоит создать собственный репозиторий пакетов, такой, как Packeton, и перенести код модулей в собственные git-репозитории. Так же, можно использовать платный репозиторий Private Packagist.

Как создать composer-пакет в приложении и зарегистрировать его как сервис в IoC-контейнере, можно посмотреть здесь: до изменений, после изменений, diff.

В примерах используется composer для управления зависимостями пакетов и Symfony Dependency Injection как IoC-контейнер для сервисов. У Вас может быть другой контейнер. Если в приложении нет IoC-контейнера, придется делать рефакторинг и реализовать внедрение зависимостей. Простейший пример добавления IoC-контейнера в приложение.

Решение проблем со связанностью кода

Есть два типа связанности:

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

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

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

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

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

Основные алгоритмы расцепления связанности:

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

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

  • Наследование от внешних классов с зависимостями надо превратить в композицию с помощью адаптеров, которые внедряются как сервисы.

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

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

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

2. Статические вызовы.

Синтаксис PHP допускает вызов статических методов у объектов как методов класса (пример). Если Вы выносите в пакет или обычную функцию или класс, у которого есть статический метод, эти функции/методы нужно добавить в публичное API пакета (пример, diff).

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

Ссылки: пример прямого статического вызова, пример инверсии зависимости статического вызова через внедрение сервиса, diff коммита.

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

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

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

5. Использование глобальных констант и констант классов.

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

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

Ссылки: до изменений, после изменений, diff, декларация инъекции константы в контейнере.

6. Динамическое разрешение имен через строковые операции.

Пример: $model = new ($modelName . Class);

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

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

Оптимизация

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

Есть несколько способов решения этой задачи:

  1. Сервисы, которые передаются в пакет, можно объявить как lazy.

  2. Объект API пакета можно объявить как Service Subscriber.

  3. Разделить API пакета на несколько сервисов.

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

Service-Oriented Architecture

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

У каждого пакета зафиксирован публичный API. На основе этого API можно создать сервис с restful-протоколом. Код нового сервиса - это код пакета, вокруг которого написан достаточно стандартный роутинг, запись логов, и прочий инфраструктурный код. А в старом коде вместо кода пакета появляется адаптер для http-вызовов через curl.

При создании отдельных внутренних приложений-сервисов надо решить две задачи:

  1. Детальное протоколирование вызовов всех сервисов. Каждому клиентскому запросу надо присваивать уникальный ID вызова, который передается во все сервисы при вызовах внутренних API, и каждый вызов сервиса надо протоколировать. Надо иметь возможность отследить вызовы сервисов по цепочке.

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

Заключение

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

Подробнее..

Как сделать хорошую интеграцию? Часть 1

29.12.2020 12:11:44 | Автор: admin
Вопрос в заголовке включает в себя неочевидную часть, ведь перед тем, как рассказывать про создание хорошей интеграции стоит определить, какую интеграцию мы считаем хорошей. А ответ на этот вопрос не однозначен.

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



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

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

Хорошая интеграция это интеграция с хорошей админкой


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

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

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

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

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

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

При обработке сообщений


Прием сообщений не должен полностью останавливаться на первой же ошибке


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

Необходимо контролировать последовательность обработки сообщений


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

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

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

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


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

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

Надо уметь запустить сообщение на обработку в системе-получателе


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

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

Надо уметь найти сообщение в системе-источнике и повторно его отправить


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



Интерфейсы работы с инцидентами должны быть ориентированы на массовую обработку


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

При изменении объектов


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

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

Поддержка распределенных ограничений целостности


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

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

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



Сверка данных


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

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

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

Уведомления


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

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

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


На этом я заканчиваю сегодняшнюю статью.

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

На весенний и осенний сезоны 2021 года открыт прием докладов на конференции. Для 2021 года мы подготовили 14 конференций, в том числе и перенесенных с этого года. Смотрите план наших конференций на весь 2021 год с датами закрытия Call for Papers.
Изучайте, подбирайте конференцию для себя!
Подробнее..

Perfomance-менеджмент через оценки от идеи до бета тестирования

05.01.2021 14:11:03 | Автор: admin

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

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

MVP-версия продукта стартовала как Open Source решение и его развитие должно было происходить в свободное от основных задач время

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

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

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

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

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

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

Оценка - количественное выражение достижения команды, участника или отдела в целом. Мы решили, что два типа оценок для начала будет вполне достаточно:

  1. Качественная (soft skill) - оценивает качества разработчика или проект менеджера, например: умение найти общий язык, ответственность, пунктуальность и т.д.

  2. Техническая (hard skill) - оценивает работу с точки зрения технических знаний участника, например чистота кода, знание архитектуры и т.д.

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

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

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

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

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

Backlog. В настоящий момент это список вопросов с радио кнопкамиBacklog. В настоящий момент это список вопросов с радио кнопками

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Благодаря системе работа действительно стала намного прозрачнее.

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

  • Отслеживать цели сотрудников

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

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

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

Бэклог в настоящий момент довольно огромный. Планируется запустить:

  • Функцию Спасибо, когда участник команды может вне задач благодарить коллег

  • Система достижений как элемент геймификации

  • Карма

  • Внутренняя валюта, за которую можно приобрести мерч или другие плюшки

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

  • Градация роста по карьерной лестнице

Благодарности

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

Также большая благодарность Habr-площадке за возможность рассказать о своем опыте.

Большое всем спасибо!

Дополнительные материалы

Ссылка на проект:

https://github.com/wooppay/wrs/

Изображения персонажей ролей для статьи были созданы при помощи The Character Creator

https://github.com/ubik23/charactercreator

Рамки для изображений в статье были использованы из freepik.com

www.freepik.com/psd/mockup

www.freepik.com/psd/technology

Подробнее..

GTK Как выглядит первый запуск анализатора в цифрах

04.01.2021 10:13:21 | Автор: admin

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

Введение

GTK кроссплатформенная библиотека элементов интерфейса. Недавно состоялся релиз GTK 4, что стало хорошим инфоповодом изучить качество кода проекта с помощью статического анализатора кода PVS-Studio. Такая деятельность для нас является регулярной, и нам часто приходится настраивать анализатор с нуля на многих проектах перед исследованием качества кода. В этой заметке я поделюсь опытом быстрой настройки PVS-Studio на C++ проекте.

Анализ GTK

Первые результаты

Получаем свой первый отчёт анализатора и видим следующие результаты для диагностик общего назначения:

4 (Fails) + 1102 (High) + 1159 (Medium) + 3093 (Low) = 5358 предупреждений.

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

Исключаем директории

Рассмотрим такое предупреждение:

V530 [CWE-252] The return value of function 'g_strrstr_len' is required to be utilized. strfuncs.c 1803

/* Testing functions bounds */static voidtest_bounds (void){  ....  g_strrstr_len (string, 10000, "BUGS");  g_strrstr_len (string, 10000, "B");  g_strrstr_len (string, 10000, ".");  g_strrstr_len (string, 10000, "");  ....}

Это код тестов, причём не относящихся непосредственно к GTK, поэтому составляем список директорий для исключения из анализа и перезапускаем PVS-Studio.

При следующем запуске из анализа будут исключены следующие директории:

gtk/_build/gtk/subprojects/gtk/tests/gtk/testsuite/

Открываем отчёт и получаем следующий результат:

2 (Fails) + 819 (High) + 461 (Medium) + 1725 (Low) = 3007 предупреждений.

Ещё один положительный эффект, который мы получили после такой настройки, это ускорение анализа.

Исключаем макросы

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

V501 There are identical sub-expressions '* (& pipe->ref_count)' to the left and to the right of the '^' operator. gdkpipeiostream.c 65

static GdkIOPipe *gdk_io_pipe_ref (GdkIOPipe *pipe){  g_atomic_int_inc (&pipe->ref_count);  return pipe;}

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

#V501//-V:g_atomic_int_:501#V547//-V:GTK_IS_:547//-V:GDK_IS_:547//-V:G_IS_:547//-V:G_VALUE_HOLDS:547#V568//-V:g_set_object:568

Всего несколько строчек, которые покрывают большинство проблемных макросов для V501, V547 и V568.

Смотрим результат:

2 (Fails) + 773 (High) + 417 (Medium) + 1725 (Low) = 2917 предупреждений.

Отключаем диагностики

Некоторые диагностики изначально выдают неподходящие предупреждения для конкретного проекта. Рассмотрим предупреждение V1042:

V1042 [CWE-1177] This file is marked with copyleft license, which requires you to open the derived source code. main.c 12

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

2 (Fails) + 164 (High) + 417 (Medium) + 1725 (Low) = 2308 предупреждений.

Изучаем фейлы

В проекте имеются 2 предупреждения типа Fails:

  • V002 Some diagnostic messages may contain incorrect line number in this file. gdkrectangle.c 1

  • V002 Some diagnostic messages may contain incorrect line number in this file. gdktoplevelsize.c 1

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

Эти предупреждения можно просто проигнорировать.

Выводы

Итоговый результат такой:

164 (High) + 417 (Medium) + 1725 (Low) = 2306 предупреждений.

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

V501 There are identical sub-expressions 'G_PARAM_EXPLICIT_NOTIFY' to the left and to the right of the '|' operator. gtklistbase.c 1151

static voidgtk_list_base_class_init (GtkListBaseClass *klass){  ....  properties[PROP_ORIENTATION] =    g_param_spec_enum ("orientation",                       P_("Orientation"),                       P_("The orientation of the orientable"),                       GTK_TYPE_ORIENTATION,                       GTK_ORIENTATION_VERTICAL,                       G_PARAM_READWRITE |                       G_PARAM_EXPLICIT_NOTIFY |  // <=                       G_PARAM_EXPLICIT_NOTIFY);  // <=  ....}

Это отличный результат! И показатели других диагностик тоже значительно выросли. Мизерными настройками удалось уменьшить отчёт анализатора на целых 57%. Соответственно, показатель верных предупреждений к ложным тоже значительно вырос.

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

А теперь время передать эстафету моему коллеге Андрею Карпову.

Примечание Андрея Карпова

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

Конечно, моя задача проще и сильно отличается от процесса настройки и внедрения анализатора в реальный проект. Мне достаточно поверхностно пробежаться по списку предупреждений и выписать явные ошибки, игнорируя ложные срабатывания или непонятные предупреждения в сложных участках кода. При реальном использовании понадобится больше времени, чтобы настроить анализатор, точечно подавить ложные срабатывания, улучшить макросы и так далее. Но на самом деле, это не страшно. Например, в статье про проверку проекта EFL Core Libraries я показал, что можно достаточно легко настроить анализатор, чтобы он выдавал всего 10-15% ложных предупреждений. Согласитесь, неплохо, когда на каждые 1-2 ложных срабатывания вы исправляете 8-9 ошибок.

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

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

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Svyatoslav Razmyslov. GTK: The First Analyzer Run in Figures.

Подробнее..

Важность диалога между PM-ом и разработчиком

28.12.2020 10:22:36 | Автор: admin

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

Кейс разработки.
Разработчик завис над простой задачей. Занимался задачей две недели. По результатам двух недель работы внес в репозиторий изменений на 10-20 строк кода. В отчете по задаче множество технических деталей. В отчете выставил необходимость дополнительного времени на доработку задачи.

Если для вас кейс очевиден, то можно дальше и не читать.

Список проблем.

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

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

Возможность конфликта с разработчиком.


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

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

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

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

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

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

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


И так далее. (Прописываю только часть проблем.)

Решения.


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

Спасибо.

Подробнее..

Перевод Маленькие задачи, а доверия ещё меньше

12.01.2021 12:17:05 | Автор: admin


Почему делегирование обязанностей лучше, чем распределение задач


Доверие высочайшая форма мотивации. Оно выявляет в людях самое лучшее.

Стивен Р. Кови, Семь навыков высокоэффективных людей

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

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

Наконец-то, у нас появился Винсент, я могу поручить ему заняться A и B; Тед будет делать C, D
и E, Джен займётся F, G и H, а я смогу добраться до I, J, K, L и M.

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

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

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

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

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

Так чьё это видение?


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

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

Слишком много любви к метрикам


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

К сожалению, мелкие задачи в Jira (или в любом из десятков других систем отслеживания ошибок) приносят с собой перспективу целого множества новых вкусных графиков и диаграмм: burn down, burn up, velocity, lead time, cycle time, task age, throughput, failed deployment, flow and control. Всё это манит, как ребёнка манит конфета.

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

Когда у меня появится возможность получить опыт проектирования?


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

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

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

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

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

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

Оценка всегда требует ресурсов


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

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

Проблема в том, что как только вы начнёте работать над одним из них, то осознаете, что подразумеваемые проектные решения неверны. Теперь вам нужно потратить ГОРАЗДО больше времени, чем прежняя оценка задач, а все остальные задачи, зависящие от этого ошибочного решения, окажутся недействительными. Весь карточный домик развалится. Пришла пора ещё одного ещё дня возни с бэклогом? Какая трата времени!

Вывод


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

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

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

Я, Бартоломеу, буду обеспечивать соответствие требованиям.

Я, Васко, неплохо разбирался в Microsoft Access, поэтому, наверно, буду заниматься базами данных.

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

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



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


VDSina предлагает мощные и недорогие VPS с посуточной оплатой. Интернет-канал для каждого сервера 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!

Подробнее..

Мой опыт в самоорганизующейся команде

14.01.2021 20:16:39 | Автор: admin

Привет! Я хочу рассказать про свой опыт в самоорганизующейся команде. За полтора года в ней было от 3 до 5 разработчиков, я не занимался их наймом, но все процессы и разработку построил с нуля. Расскажу, что такое самоорганизующаяся команда, какую пользу она приносит для компании, команды, и ее участников.

Самоорганизующаяся команда

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

Команда сама выбирает технологии, занимается их исследованием (насчет релевантности, например), внедрением и поддержкой Go или Python, Jenkins или Github Actions, нужен ли Kubernetes.

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

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

Еще о процессах

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

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

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

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

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

Классно иметь модель ветвления по типу Trunk-based, когда код сразу попадает на сервера, нет отдельных веток для пред-master (develop) и релизов как это предусматривает GitFlow Workflow. У нас была одна ветка master, если пулл реквест смерджился, значит, тесты написаны, функциональность проверена на deploy preview (feature branch, review app) ничего не затягивается. Один пулл реквест один коммит в master один релиз.

Плюсы

Для разработчика быть в такой команде значит:

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

  • приобретается понимание всего цикла разработки программного обеспечения,

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

Для команды и компании:

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

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

  • нет проблем с переходом на удаленную работу команды, если это необходимо.

Минусы

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

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

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

Вывод

Я сделал следующий вывод для себя:

  • мне комфортно так работать,

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

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

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

Подробнее..

Как перестать впаривать и начать развивать продукт, привлекая новых клиентов

23.12.2020 22:19:01 | Автор: admin
Мы привыкли, что менеджеры по продажам должны продавать, а разработчики разрабатывать. А что, если есть такая магия, которая позволяет разработчикам вшивать продаваемость прямо в продукт



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

Персоны


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

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

  • мужчины/женщины 60/40
  • возраст 24-55
  • интересы: развлечения, путешествия, IT, активный отдых, дети
  • плюс многие другие параметры, которые могут быть важны или не важны.

Что нам это дает? Почти ничего.

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

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

Разбираясь с нагрузкой, вот что мы выяснили: примерно 70% трафика в это самое прибыльное время приходилось на женщин 25-40 лет с интересами дети, красота, мода, развлечения. Давайте дополним этот портрет фактом покупки одежды в интернете в поздние вечерние часы и можно получить вот такую Персону:

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

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

Работы


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

Если не очень наглядно, то давайте обратимся к нашей с вами Ане, 27 лет, которая после того, как её малыш уснул, вместо шоппинга может отправиться, например, на электронные курсы по дизайну, чтобы украсить свой Instagram для мамочек яркими картинками. Для этого Аня установила себе Photoshop или Illustrator, которые для неё выполняют работы по созданию креативов. А может, это не Аня, а совсем другой человек, который вроде бы никак не может оказаться в одной ЦА с Аней.

Знакомьтесь, это Володя:

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

Персоны совершенно разные, а работы, которые Аня и Володя заказали у этих сервисов, одни и те же.

Зачем все это?


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

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

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

В теории персоны также неплохо подойдут для знакомства ваших разработчиков с конечным клиентом. Понадеемся, что они нет-нет, да и поставят себя на место Ани и сделают что-то именно для нее. Наверное. Вряд ли. Или точно нет, если только случайно. И вот почему: тот факт, что Ане 27 или что она в декрете, совсем не объясняет, что ей нужен Photoshop или Illustrator. Просто потому что связи между ними нет. А если рассказать разработчикам, что Ане, а кстати и Володе, нужны эти инструменты, чтобы максимально быстро и красиво делать креативы для соцсетей, поскольку они занимаются дизайном и SMM, то это будет для них куда полезнее.

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

Как работают Работы?


Чтобы помочь разработчикам или вообще всем, кто в этом заинтересован извлечь пользу из знаний о Работах, вот по такому шаблону составляются Job Stories,:

  1. [описание ситуации/контекст]. Я веду блог для таких же мамочек, как я сама. Или я веду страничку на Behance с эскизами аэрографии.
  2. [мотивация]. Я хочу иметь удобный инструмент для создания креативов для своего блога в соцсетях.
  3. [результат]. Чтобы получать классные результаты, которые будут выделять меня качеством работ и профессиональным уровнем реализации.

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

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

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

Теперь на минутку вернемся к Персонам. Позволит ли описание Персоны Ани, 27 лет сделать такие же выводы? Конечно, нет. Это основное отличие Работ от Персон. Они хороши каждая по-своему, но в разных ситуациях.

Так что же выбрать?


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

Про Работы и Job Stories мы узнали, что они позволяют выявить направления разработки и приоритезировать их. Конечно же можно использовать такие примеры решения болей потребителя и в рекламных кампаниях, это тоже работает.

Если вы дочитали до этого места, значит, вам интересно и специально для вас есть еще один рецепт как использовать Персоны и Job Stories. А именно вместе. Они отлично дополняют друг друга. Усиливайте рекламные кампании, настроенные на Персон иллюстрациями Job Stories, тогда первые привлекут внимание, а вторые послужат триггером для клиента.

Тут отличным примером станет мой собственный проект про карты охотничьих угодий. Мы уже какое-то время были на рынке, что-то продавали и думали, что продаем карты в 91% случаев мужчинам -, в возрасте от 25 до 55 в 75% случаев и, естественно, с интересами охота, рыбалка, активный отдых и другими совершенно бесполезными характеристиками. Обо всем этом нам рассказал Google Analytics. Как такую аудиторию не разбивай на сегменты, ничего не получишь, мы пробовали. Мы провели больше сотни интервью с пользователями. И независимо от возраста, места жительства и уровня дохода, все говорили примерно одно и то же: карты им не нужны, места они знают не заблудятся, а если охотятся на новом месте, то с егерем. Но карты продолжали покупать. Мы провели ещй почти сотню интервью теперь уже с платящими пользователями. Узнали одну простую вещь, которая объединяла всех, кто покупал наше решение: им нужны не карты, им не нужны проблемы с охотинспекцией, которые возникают при нарушении границ угодий. То есть мы продавали не карты, мое приложение нанимали, чтобы исключить проблемы с охотинспекцией.

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

Тактика и стратегия


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

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

Вот Job Story для меня, как потребителя такого сервиса:

  1. [описание ситуации/контекст]. У меня есть сегодня встреча в центре города
  2. [мотивация]. Я хочу попасть на эту встречу и не опоздать
  3. [результат]. Чтобы не выглядеть непунктуальным человеком

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

Можно до бесконечности улучшать свой продукт и победить другие агрегаторы такси и все равно проиграть в конце. Вспомните Nokia Это понимают самые дальновидные игроки и делают ставку на постоянное внедрение инноваций. Мой любимый пример это iPod, его разбирали, как горячие пирожки в базарный день, и вот Apple выпускает iPhone, который практически убивает свой же собственный продукт. Но вместе с ним убивает и почти все остальные смартфоны на рынке, оставляя за собой при этом и весь рынок, который принадлежал iPod.

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


Что в итоге



Теперь мы знаем, кто, когда и для каких целей может использовать Работы и весь фреймворк Jobs to be done, а когда можно обойтись и методом Персон. Но подводя итог, важно подчеркнуть: если вы развиваете свой стартап всерьез и надолго, то критически важно пользоваться методологией Jobs to be done. Придется смириться с тем, что любой бизнес, который заключается в производстве и реализации продукта, заведомо проиграет бизнесу, который пользователь нанимает на работу для решения своих проблем. Понимание этих различий переведет вас и ваш бизнес из разряда просто хороших компаний в разряд инновационных.
Подробнее..

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

12.01.2021 18:23:11 | Автор: admin

Один из интересных и не очень часто освещаемых вопросов ИТ-менеджмента расширение команды инженеров и ошибки, которые можно совершить на этом пути. Я сам активно развиваю свои проекты и поэтому интересуюсь этой темой. Мне удалось поговорить с Алиной Зурабовой, Head of Engineering and Testing в компании Smartcat. Этот стартап с российскими корнями, который развивает платформу управления переводами и привлек более $14 млн. Соответственно, за последние пару лет серьезно выросла и его техническая команда.

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

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

За несколько лет активной работы мы устаканили видение продукта, поняли, как именно он должен выглядеть хотя бы на текущий момент понятно, что все может меняться. Мы разобрались с тем, кто наши клиенты, какие у них боли и проблемы то есть нащупали, как говорят в США, product/market fit.

В частности, стало ясно, что наша модель это all-in-one-product, то есть мы хотим сделать систему, которая покрывает все бизнес-процессы пользователей разных ролей внутри индустрии переводов. Здесь есть и заказчики, которым нужно как-то получить перевод, и компании-поставщики таких услуг, а есть конечные исполнители, которые переводят контент. Мы хотим автоматизировать работу каждого участника этой цепочки.

При этом под капотом:

  • извлечение переводимого текста из файлов офисных форматов,

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

  • маркетплейс переводчиков (их умный подбор, тестирование и ранжирование внутри конкретного аккаунта),

  • поддержка мультиюзерного сценария работы внутри CAT-системы,

  • система биллинга и инвойсирования, работающая в интеграции с разными платежными провайдерами),

  • и т.п.

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

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

Урок #1: структура внутри команды не должна ограничивать рост

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

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

От этой модели при расширении команды пришлось отказаться по ряду причин:

  • звено менеджера стало бутылочным горлышком, bus factor начал зашкаливать;

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

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

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

Начали думать, как изменять модель, чтобы победить все эти сложности. В итоге (ничего нового я вам не открою) пришли к тому самому Scrum-процессу. Каждая команда отвечает за один из элементов цепочки продукт для заказчиков перевода, сервис-провайдеров или конечных исполнителей, задачи дробятся в рамках этих направлений (платежи, подбор исполнителей, отчетность и т.п.) Такую систему можно без проблем масштабировать и адаптировать под потребности бизнеса, да и потери и TTM (Time To Market) там меньше.Одним из важных шагов на пути прихода к такому сетапу стала книжка Hyper Growth, если бы знала о ней раньше могли бы пройти некоторые шаги и сделать открытия гораздо быстрее. В общем, да, рекомендую к прочтению всем IT-менеджерам, потом не забудьте сказать мне спасибо за 70 листов отборной полезной информации.

Урок #2: нужно четко планировать расширение команды и адаптировать процессы

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

Первый шаг на пути тестирования гипотезы all-in-one-product заключался в создании еще одного важного компонента системы маркептлейса исполнителей.

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

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

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

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

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

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

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

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

Урок #3: в стартап нужно нанимать особенных инженеров

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

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

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

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

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

Выводы: о чем помнить при расширении IT-команды в стартапе

В завершение, еще раз выделим ошибки и возможные решения:

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

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

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

Делитесь своими примерами трудностей при развитии технической команды в стартапе соберем максимально полный список проблем и решений в комментариях!

Подробнее..

Чипирование в ЭКО, VR в медицине и нейросети в УЗИ

29.12.2020 08:14:25 | Автор: admin

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

Гость Дмитрий Фомин. Дмитрий основатель сети клиник женского здоровья Клиника Фомина и генетической лаборатории Medical Genomics. Он адепт искусственного интеллекта и технологий, активно внедряет их в своей клинике, чем нас и привлек. Сейчас активно занимается созданием рекомендательной системы для врачей на базе ИИ и BigData, которая не только несет пользу для пациентов, но и имеет научную ценность.

Чипирование в ЭКО

Фаря:

- Прежде всего очень интересно, что такое чипирование биоматериала при ЭКО? Что там в эмбрионе можно чипировать?

Дмитрий:

- Судя по формулировке, это, наверно, выглядит, будто человека чипируют еще до рождения?

- Ага, анти-5G-шники нас сейчас заклеймят.

- На самом деле, чипируют, конечно, не сам эмбрион. Но сначала расскажу историю.

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

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

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

- Это стресс.

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

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

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

- Это на экране зародыш человека? А что вы от него отрезаете?

- Это самый частый вопрос: а что вы забрали - ручку или ножку? Не волнуйтесь, на самом деле мы берем нужные клетки из плаценты.

Искусственный интеллект в УЗИ

- Какие уникальные технологии вы разрабатываете?

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

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

Во-первых, врач должен сделать несколько срезов: справа, слева, сверху, снизу и так далее. ИИ за этим следит. А также за тем, зафиксировал ли врач срезы в нужной последовательности.

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

Все это напрямую влияет на дальнейшее принятие решений.

- Есть ли вероятность, что со временем во многих задачах врач не будет нужен?

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

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

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

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

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

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

Хотя еще двадцать лет назад ЭКО стоило 20 тысяч долларов, как квартира. Сегодня - 3000 долларов. И всё это будет дешеветь, дешеветь и дешеветь. Но и количество потребления из-за этого тоже будет расти.

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

Мы в самой современной операционной, где проводят операции в VR

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

Сама операционная синхронизирована по видео с конференц-залом, а также по оптоволокну с другими странами и городами. Люди, которые смотрят на операцию из Нью-Йорка, надевают очки и тоже видят процесс в 3D для обучения.

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

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

- А оценивать эффективность лечения можно?

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

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

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

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

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

Подробнее..

Профессионализм разработчика на шаг ближе к счастью

05.01.2021 16:09:52 | Автор: admin

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

Счастье и удволетворенность работой

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

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

В чем проблема?

Проблема в том, что бизнес не всегда знает, что для него лучше. Представители бизнеса менеджеры, специалисты по продукту, аналитики и многие другие профессионалы намного лучше разработчика умеют отвечать на вопрос что делать? (произведение Н. Чернышевского не имеет к этому никакого отношения). Но никто не обладает большей экспертизой в разработке ПО чем разработчики (а также архитекторы, технические менеджеры и другие специалисты обладающие знаниями и hard skills в области разработки). Их задача предоставить бизнесу свою экспертизу, валидировать его идеи и отвечать на вопрос как делать?. Идея такого взаимодействия лежит в основе методологии Agile (https://agilemanifesto.org/).

Внимательный читатель заметит, как я прибегаю к приему *argumentum ad auctoritatem (аргумент к авторитету).* Но в мире мнений и субъективных суждений, в котором мы живем это хороший прием, и я советую прибегать в том числе и к нему для донесения профессионалом своей идеи.

Мнение профессионала о том, что полезно для бизнеса субъективно. Это мнение, которое, возможно, не является истиной в последней инстанции и, как любое мнение, может быть ошибочно errare humanum est. Тем не менее, я считаю что разработчику стоит бороться за те идеи, в которые он верит как профессионал.

Что можно попробовать сделать?

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

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

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

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

Кого и как убеждать?

Если с идеей разработчика согласны все, кто влияет на ее принятие, тогда она принимается и результатом становится однозначный успех. Но эта ситуация выглядит идеализированной, и, скорее всего, возникнут спорные ситуации, которые потребуют разрешения. Я считаю, что в случае разработки ПО есть две стороны, которые разработчик может убедить в правоте своих суждений. Первая горизонтальная это другие разработчики, так как невозможно внедрить практики, например TDD (разработка через тестирование) или code review, если это делает один человек в команде. Вторая вертикальная представители бизнеса, так как применение best practices, особенно когда их внедрение только начинаются, требует времени разработчиков.

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

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

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

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

Заключение

Эта статья глубоко субъективное мнение о том, как разработчику получать больше удовольствия от своей работы за счет проявления профессионализма и донесения до бизнеса субъективных идей, которые разработчик, как профессионал, считает верными. Статья во многом вдохновлена идеями Agile, книгой Clean Architecture Роберта Мартина, а также собственным опытом, переживаниями и опытом знакомых и коллег.

Подробнее..

CloudMaster это про самообслуживание разработчиков в корпоративном ЦОДе и облачных сервисах

25.12.2020 18:10:30 | Автор: admin
Здравствуйте! Я Игорь Гальцев, с 2010 технический руководитель различных направления разработок Softline в области автоматизации управления и продаж облачных (подписочных) сервисов.

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



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


В чем проблема


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

Разрабатывая параллельно несколько сотен проектов, суммарно ресурсов AWS, Azure и GCP клиент потребляет ежемесячно на полмиллиона долларов. А за год создает и удаляет порядка 350 тыс. виртуальных машин.

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

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

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

Самообслуживание через платформы управления облаками (CMP)


Навести порядок в нескольких используемых облаках, частных или публичных, помогают решения класса Cloud Management Platform. Я хочу рассказать о российской альтернативе от наших партнеров платформе CloudMaster, ориентированной на подключение к Azure, AWS и Google Cloud, а также приватным регионам под vCloud Director, vSphere и OpenStack.

С точки зрения разработчика, CloudMaster это портал самообслуживания, где через единый интерфейс и без бюрократии (через UI в браузере, мобильном приложении и консольных командах (Python-скрипты)) можно получать ресурсы в корпоративном облаке или ЦОД. А для инфраструктуры это дополнительный уровень абстракции между облачными платформами и конечными пользователями, на котором сохраняется избирательный общий доступ к ресурсам, политики безопасности, стандартные конфигурации и прочие необходимые инструменты вроде образов машин и Terraform-шаблонов.

Основная часть CloudMaster сделана на Java и базируется на основе фреймворков Spring на сервер-сайде и Dagger в Android-приложении.

Архитектурно CloudMaster заточен на работу с большими командами и значительными объемами отправляемых сообщений: для обработки очередей использован RabbitMQ, для хранения данных MonogoDB, для балансировки Nginx.



Разрабатывался инструмент с 2012 года, а с 2014-го применяется у крупного разработчика софта.

Логика CloudMaster


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

Для доступа к этому единому окну достаточно регистрации на портале. А при наличии интеграции CloudMaster с корпоративным AD роли сотрудников в компании и в проекте будут загружены в этот инструмент, автоматически определяя доступные проекты и ресурсы.


Окно запуска виртуальной машины

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


Типовые шаблоны для разных облаков

Можно создавать образы из существующих машин, пользоваться готовыми шаблонами инфраструктура как код или загружать свои (Terraform и CloudFormation).


Шаблоны

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

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


Список ресурсов


Список виртуальных машин

Помимо отображения информации в интерфейсе, CloudMaster генерирует порядка 60 типов уведомлений, в том числе касающиеся финансов.


Пришедшие уведомления


И текст одного из уведомлений

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

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


Биллинг от облачных провайдеров


Окно управления квотами

Для частных облаков (OpenStack и VMware) CloudMaster поддерживает своего рода биржу оценку стоимости запуска виртуальных машин, с помощью которых можно выбирать более выгодную схему утилизации ресурсов. Коллеги говорят, что в будущем такая функция может появиться и для публичных облаков.

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

При необходимости для администраторов и разработчиков есть Java SDK.
Самое главное, что CloudMaster, как и другие CMP, позволяет перейти от ручного рутинного выделения ресурсов к более интересным задачам: проработке автоматизаций на базе инфраструктура как код и т.п.

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

Категории

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

© 2006-2021, personeltest.ru