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

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

Перевод Крупные компании, использующие Node.js

13.04.2021 12:15:42 | Автор: admin


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

Она написана на самом популярном в мире языке программирования JavaScript, поэтому открывает новые возможности для многих бизнесов. Неудивительно, что она стала высокоактуальной технологией, выбранной многими компаниями, в том числе такими крупными, как Netflix и PayPal. Какие компании используют технологию Node.js и какие выгоды она им даёт? Об этом мы расскажем в статье.

Действительно ли Node.js меняет рынок?


Согласно данным Stack Overflow, Node.js абсолютный лидер в мире технологий, занимающий 50,4% рынка. Почему же он стал столь популярным?

Согласно последнему отчёту Node.js, эта технология оказывает на бизнес значительное влияние: она обеспечивает рост продуктивности разработчиков на 68%, на 48% повышает производительность приложений, и на 13% качество обслуживания клиентов. Более того, похоже, что эти значения со временем растут:

image

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

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

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


Учитывая длинный список преимуществ применения Node.js, легко поверить, что среди крупнейших компаний, использующих эту технологию, есть такие как НАСА, Uber и Twitter. Кто пользуется Node.js, почему они решили перейти на Node.js и чем это для них обернулось?

Netflix


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

Преимущества, полученные Netflix:

  • После перехода на технологию Node.js время запуска снизилось на 70%. Раньше загрузка интерфейса Netflix занимала до десяти секунд, а теперь всего секунду;
  • Node.js упростил интеграцию микросервисов и разбиение огромного блока информации на подробный интерфейс;
  • Переход от бэкенда к фронтенду был значительно ускорен, поскольку среда Node.js основана на JavaScript.

НАСА


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

Преимущества для НАСА:

  • Время доступа снизилось на 300%, что позволило пользователям получать информацию за секунды, а не за часы;
  • НАСА успешно перенесла старые базы данных в облако и обеспечила доступ к ним через API;
  • Node.js сократил процесс работы с базами данных с 28 шагов всего до семи, что значительно упростило научные исследования.

Trello


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

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

  • Node.js предоставил возможность создания чрезвычайно облегчённого одностраничного приложения;
  • Благодаря Node.js Trello может обрабатывать обновления с нулевыми задержками;
  • Архитектура Node.js позволила сократить затраты на разработку и прототипирование.

Переход компании PayPal на Node.js


Система PayPal, имеющая более 200 миллионов активных аккаунтов, является мировым лидером отрасли онлайн-платежей и переводов. В 2013 году компания столкнулась со сложностями, вызванными Java, которые плохо сочетались с фронтенд-разработкой. Java обеспечивала длительное время разработки, а также низкую производительность, поэтому PayPal стала одной из компаний, использующих Node.js.

Полученные PayPal результаты:

  • Меньшая по размерам команда разработчиков создала приложение Node.js за более короткое время;
  • Снизилось время отклика, что привело к уменьшению времени загрузки на 35%;
  • После внедрения технологии Node.js количество пользовательских запросов в секунду удвоилось.

LinkedIn


Ещё одна компания, использующая Node.js это LinkedIn, крупнейшая социальная платформа для бизнеса и трудоустройства. Её популярность продолжает расти, а база составляет 467 миллионов пользователей из более чем 200 стран. После перехода с Ruby on Rails на Node.js компания создала приложение, работающее в десять раз быстрее старой версии. Решение было принято из-за синхронизации приложения на Ruby, которая приводила к повышению времени загрузки, особенно при увеличении объёма трафика.

Полученные LinkedIn преимущества:

  • Вся архитектура LinkedIn создавалась на JavaScript, что упростило обработку клиент-серверных взаимодействий;
  • Количество серверов сократили с тридцати до трёх, что удвоило пропускную способность по трафику.

Опыт Uber с Node.js


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

Полученные Uber выгоды:

  • Node.js позволил Uber намного быстрее обрабатывать огромный объём данных и многочисленные запросы пользователей;
  • Благодаря технологии Node.js компания Uber способна ежедневно обслуживать 14 миллионов поездок;
  • Uber повысила связность системы и снизила затраты на управление, создав более 600 конечных точек без сохранения состояния.

Переход на Node.js пример Twitter


Более 80% владельцев аккаунтов Twitter получают к ним доступ через смартфон, поэтому компания приняла решение о создании Twitter Lite приложения с минимальными функциями, способного работать даже при плохом Интернет-соединении. Кроме того, веб-сайтная версия Twitter не была оптимизирована под плохие условия соединения. Всё это привело к тому, что Twitter стала одной из компаний, использующих Node.js.

Преимущества для Twitter:

  • Twitter Lite занимает мало места от 1% до 3% памяти телефона, что удобно для пользователей мобильных устройств;
  • Приложение работает даже с подключениями 3G и 2G;
  • Затраты на поддержку Twitter Lite значительно ниже, чем у Twitter Desktop.

eBay


Ещё одним бизнесом, использующим Node.js, является eBay. Имеющий 183 миллионов пользователей eBay это крупнейшая торговая площадка, предоставляющая услуги онлайн-продаж C2C и B2C. Раньше приложение eBay работало на Java, что приводило к долгой загрузке и низкой производительности. Так как eBay это платформа с огромным объёмом трафика, ей требовалась технология, которая бы ускорила разработку, чтобы она поспевала за изменениями во фронтенде.

Выгода для eBay:

  • eBay создала при помощи Node.js микросервисы, которые выполняются в реальном времени и не перегружают инфраструктуру.
  • Node.js обеспечил масштабируемость, скорость и масштабируемость.

Groupon


Groupon крупнейшая площадка, на которой представлены купоны, скидки и выгодные предложения, она имеет базу в 40 миллионов пользователей. Когда в 2019 году Groupon достиг отметки в 200 миллионов скачиваний, то столкнулся с проблемами масштабируемости. Именно тогда компания обратила внимание на Node.js и провела крупнейшее в мире развёртывание продукта на Node.js.

Преимущества, полученные Groupon:

  • Развёртывание Node.js обеспечило высокую масштабируемость, что позволило реализовать бесперебойную работу 3400 бэкенд-сервисов;
  • Скорость загрузки удвоилась;
  • Node.js упростил и ускорил миграцию на другую платформу.

Medium


Medium это известная платформа для онлайн-публикаций с 85 миллионами пользователей, использующая Node.js. Достигнув в 2016 году планки в 7,5 миллионов постов, команда Medium ощутила потребность в управлении big data без превышения нагрузки на сервера. Кроме того, компании нужно было соответствовать постоянно растущим требованиям текстовых редакторов к публикации постов.

Преимущества для Medium:

  • Даже страницы с большими изображениями и объёмным контентом грузятся за 2,7 секунды.
  • Node.js повысил качество обслуживания пользователей и ускорил время развёртывания.

TechMagic


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

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

Elements.cloud это компания, помогающая другим бизнесам в визуализации и организации бизнес-процессов. Самой большой сложностью для Elements.cloud стала реализация инструментов настраиваемой привязки процессов и визуализации на фоне автоматизированной масштабируемости инфраструктуры бэкенда. TechMagic помогла Elements.cloud в создании высокомасштабируемого и экономичного приложения на основе инфраструктуры Node.js и AWS.

Заключение


Если вы всё ещё не уверены в том, что Node.js это технология будущего, перечислю других крупных игроков, использующих её в своей работе: Google, Yahoo, Mozilla, Microsoft и многие другие. Благодаря её неограниченным возможностям всё больше компаний внедряет технологию Node.js. Однажды эта набирающая обороты технология завоюет рынок и станет лучшим фреймворком для каждой компании, от стартапов до крупных компаний. Если у вас есть задумка какого-то продукта, то подумайте над использованием Node.js в качестве его бэкенда.



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


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

Подробнее..

МойОфис представил общедоступные веб-редакторы. Теперь ознакомиться с продуктами компании можно прямо в окне браузера

07.04.2021 12:05:29 | Автор: admin

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


Привет, Хабр! В новом релизе 2021.01 мы провели комплексную работу над оптимизацией линейки продуктов МойОфис. Часть наиболее любопытных изменений коснулась технологии автономного модуля редактирования (АМР). Для иллюстрации возможностей AMP мы интегрировали модуль в корпоративный сайт МойОфис, и теперь работа с текстовым и табличным редакторами доступна всем посетителям сайта прямо из окна их браузера.

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

Что такое АМР?

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

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

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

Что умеют веб-редакторы МойОфис на базе AMP?

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

Сохранение файлов осуществляется в форматах ODT, ODS, DOCX, XLSX, PDF.

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

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

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

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

Подробнее..

Перевод Производительность главнее всего

04.04.2021 16:09:41 | Автор: admin
image


Как создать быстрое программное обеспечение?

Неверный способ


Если вы программист, вы, вероятно, знакомы с этой цитатой Кнута:

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


Многие программисты считают, что это нормальный способ разработки продуктов:

image

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

image

Я считаю эту логику ошибочной. Если ваша программа все еще является прототипом и выполняет, например, 1% (20%, 50%, 90%) того, что она должна делать, и она уже работает медленно, то она будет еще более медленной после того, как вы ее закончите, разве нет? Если вы заставите ее делать больше, почему он должна стать быстрее?

Если кто-то говорит:

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


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

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

Может показаться, что в истории полно программ, которые после выпуска стали работать быстрее. Всего несколько примеров всплывают в памяти: Chrome известен как пионер многих улучшений скорости JS. Компиляторы Kotlin и Rust получили много ускорений. VS Code / Atom в конечном итоге стали более быстрыми версиями своих оригинальных прототипов Electron. И я не говорю, что невозможно ускорить программы после выпуска. Я говорю, что эти улучшения случайны. Им просто повезло. Они могли никогда не случиться так легко, как раньше.

Верный способ


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

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

Затем, если вы действительно серьезно относитесь к результативности вашей окончательной программы, каждое решение должно приниматься с учетом производительности. Платформа, язык, архитектура, фреймворк, пользовательский интерфейс, бизнес-задачи, бизнес-модель. Можно ли их сделать быстрыми? Можем ли мы использовать язык X или фреймворк Y, можно ли их сделать быстрыми? Можем ли мы сделать эту функцию быстрой? Если нет, то чем ее заменить? Как сделать интерфейс быстрым? Как сделать так, чтобы он появлялся быстро? Подобные решения легко принять на раннем этапе, но невозможно изменить позже. Например, за последние годы скорость JavaScript впечатляла, но он все еще не может быть таким же быстрым, как C ++ или даже Java. Если бы вы поставили перед собой цель создать быстрый язык, в итоге вы бы создали другой язык!

Позвольте мне сформулировать это так:

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

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

07.04.2021 16:22:59 | Автор: admin


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

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

Об этой проблеме меня заставила задуматься первоапрельская статья Доказательное программирование

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

А что должно быть в конце прогресса у развития такой дисциплины как программирование? Или хотя бы у одного конкретного языка? Ради достижения какой конечной идеальной цели разрабатываются новые стандарты языков программирования?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перевод Код-ревью в IDE интеграция между Space и IntelliJ IDEA 2021.1

08.04.2021 20:08:42 | Автор: admin

Привет, Хабр!

Вчера вышло обновление IntelliJ IDEA 2021.1. В него вошла интеграция с JetBrains Space, которая позволяет использовать любую IDE на платформе IntelliJ для код-ревью: назначать ревью и управлять ими, просматривать и добавлять комментарии, принимать изменения. Как это работает, мы подробно расскажем в этом посте.

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

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

Видео

Если вы предпочитаете видео, смотрите обзор этой функциональности от Триши Ги:

Space-плагин встроен в свежую версию IntelliJ IDEA 2021.1. Для других наших IDE плагин нужно установить вручную.

Прежде чем приступить к ревью кода, войдите в Space из IDE. Это можно сделать в настройках: Tools | Space. Введите URL-адрес своей организации Space, нажмите Log In, и ваш дефолтный браузер попросит вас предоставить доступ из IDE.

После этого в Get from VCS появится список всех проектов и репозиториев в вашей организации Space. Найдите и выберите Git-репозиторий, с которого вы хотите начать, и нажмите Clone.

У Space-плагина есть свое окно, в котором можно просматривать задания в Space Automation. Плагин также обеспечивает автодополнение и подсветку синтаксиса для файлов .space.kts.

Но мы здесь из-за код-ревью, так что перейдем к делу.

Окно Code Reviews

Окно Space Code Reviews открывается с боковой панели или через меню Tools | Space | Code Reviews. В нем вы увидите все ревью, относящиеся к текущему проекту. В окне работает поиск и фильтры.

Фильтры помогут отсортировать:

  • Открытые и закрытые ревью;

  • Ревью, в которых содержатся ваши изменения;

  • Ревью, требующие вашего внимания;

  • Изменения, которые вам нужно просмотреть;

  • Ревью, назначенные на вас.

Хронология код-ревью

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

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

В Space важное место занимают чаты. Комментарии к код-ревью это тоже чат: оставляйте дополнительные комментарии и отвечайте коллегам в тредах. Все это не выходя из IDE.

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

Ревью кода в IDE

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

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

Принять изменения или дождаться ответа

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

  • Accept Changes, то есть принять изменения, если на ваш взгляд с кодом все в порядке.

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

В любом случае ваш этап проверки будет завершен и ваши комментарии будут опубликованы.

Заключение

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

Space-плагин встроен в IntelliJ IDEA 2021.1, а для других наших IDE его можно установить вручную.

Вы можете бесплатно зарегистрироваться в Space и легко создать зеркало существующего Git-репозитория, чтобы пользоваться всеми возможностями Space для код-ревью в IntelliJ IDEA.

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

Подробнее..

Wrike уходит от использования языка Dart. Часть 1

16.04.2021 16:20:16 | Автор: admin

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

Что такое Wrike?

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

Wrike, каким он был в 2014Wrike, каким он был в 2014

До:

Wrike 2021Wrike 2021

Столь же стремительно эволюционировали технический стек и команда разработки.

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

Gantt Chart, календари, таблицы и это далеко не полный набор возможностей WrikeGantt Chart, календари, таблицы и это далеко не полный набор возможностей Wrike

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

Краткая история технического стека

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

JS + EXT

На тот момент (2013-2014) мы уже написали достаточно внушительный объём кода на чистом JS, которому тогда не было альтернатив. В качестве основного движка (или фреймворка, если хотите) мы использовали Ext.js третьей версии. Несмотря на теперешнюю архаичность, вы будете удивлены, но он по-прежнему жив-здоров! На тот момент в нём было достаточно много прорывных возможностей, которые потом, через года, трансформировались в то, к чему мы привыкли сейчас. Например, data stores с некоторой натяжкой можно считать провозвестником привычных нам stores в React.

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

  • строгую типизацию

  • большие возможности из коробки

  • хорошую работу с большими объемами кода (сборка, минимизация и т.д.)

DART. Почему не TypeScript?

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

Ключевыми моментами в нашем выборе стали:

  • Более строгая типизация. Как показало время, и Dart, и TypeScript двинулись в сторону более строгой системы типов. Dart полностью перешёл на sound систему типов, TypeScript по-прежнему имеет с этим некоторые сложности.

  • Возможности из коробки. Порой third-party libraries могут быть очень полезны, а порой вредны. Одна из проблем современного мира web, и ее TypeScript не решает, это обилие библиотек, которые могут помочь ускорить разработку, но которые при этом нужно выбрать, поддерживать и время от времени обновлять. Шутки про node_modules уже вошли в историю. Dart при этом имеет достаточно богатую встроенную библиотеку, core библиотеки обновляются и поддерживаются самим Google

  • Агрессивный Tree-Shaking. Так как Wrike имеет огромный набор фичей, которые в итоге превращаются в большой объём кода, язык должен был помогать нам не загружать большое количество кода на клиент (см. Minification is not enough, you need tree shaking by Seth Ladd, a также github).

Эти и некоторые другие особенности убедили нас сделать выбор в пользу Dart. И, оглядываясь назад на почти шестилетнюю историю Dart и Wrike, мы видим, что выбор был правильным. Конечно, мы прошли долгий путь от Dart 1.x с его динамической типизацией и интеграцией с Polymer до AngularDart и Dart 2.x. Dart помогал нам год от года растить продукт с инженерной и бизнесовой точки зрения, продвигая компанию и продукт в лидеры рынка Work Management Platforms (Gartner and Forrester ratings).

Текущее состояние

Сейчас мы написали на Dart уже 2.5 миллиона строк кода, а кодовая база состоит из 365 репозиториев. Мы создали большое количество решений для сборки и проверки Dart-кода: например, Dart Code Metrics. Без преувеличения отметим, что Wrike один из самых больших потребителей Dart за пределами Google, что касается его web-ипостаси (появление Flutter способствовало взрывному росту популярности Dart, но пока ещё по большей мере в мире мобильной разработки).

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

Экосистема Dart

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

  • OverReact обёртка над React от Workiva.

  • Flutter for Web популярный кроссплатформенный фреймворк, написанный на Dart, с недавнего времени поддержка web вышла в стабильной версии.

  • AngularDart де-факто стандарт для разработки web-приложений на Dart.

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

Главные причины нашего ухода от разработки на Dart

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

Вдобавок к этому существуют и модные течения даже в весьма хаотичном мире фронтенда. Какое-то время назад это был прогрессивный рендеринг (React Fiber, Angular Ivy). Сейчас появляется тенденция в виде отказа от глобальных state managers, для примера можно рассмотреть Effector. GraphQL, Server Side Rendering можно найти достаточно много вещей, которые обязательно должны быть поддержаны в современном веб-фреймворке.

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

И в этом фундаменте есть два составляющих элемента:

  • Код, который ваши инженеры пишут.

  • Код, который ваши инженеры НЕ пишут.

Современная разработка (особенно на фронтенде) щедро сдобрена использованием third-party библиотек и инструментов. Да что там, сейчас можно запустить продукт на рынок, вообще не написав ни строчки кода (так называемый no-code подход)! Тем не менее, код, который вы не написали это, с одной стороны, время, которое вы сэкономили, а с другой риск, который вы берёте на себя.

Разработка крупного продукта это всегда сложный баланс между написанием собственных решений / переиспользованием готовых / взаимодействием с разработчиками сторонних фреймворков. И используемые язык и фреймворк как одни из самых обширных и всепроникающих частей разработки становятся её наиболее уязвимым местом. В былые годы, когда продукты распространялись на дисках и концепция Continuous Delivery ещё не появилась, смена языка или фреймворка могла стоить критически дорого. Сейчас же, особенно с появлением концепции micro frontends, это не только не должно быть трагедией, а, наоборот, служит здоровым механизмом эволюционного развития.

Со всем вышесказанным приходится признать, что мы пришли к точке, где нам приходится пересмотреть свой текущий технический стек как не отвечающий нашим требованиям. Несмотря на то, что язык Dart и его экосистема движутся вперёд (в том числе благодаря взрывному росту популярности Flutter), а язык Dart становится всё лучше и лучше (например, с null safety) один ингредиент всё равно отсутствует web-фреймворк. Да, в самом языке уже есть примитивы, которые позволяют работать с DOM напрямую, но такая разработка может подойти для индивидуальных разработчиков, а не для больших команд.

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

  • Feature richness. Обеспечение работы со всеми (или большинством) возможностей, которые предоставляет современный web.

  • Performance.

  • Поддержка сообщества.

  • Развитие и добавление новых возможностей.

Если более пристально посмотреть на существующие фреймворки для языка Dart, то мы увидим, что:

AngularDart

Де-факто стандарт для веб-приложений. Отвечал почти всем требованиям, но, к сожалению, Google-команда сдвинула приоритет его развития в сторону Flutter. Это следует не только из твиттера Tim Sneath (менеджер Dart & Flutter):

Переписка о судьбе AngularDartПереписка о судьбе AngularDart

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

OverReact

Портированная версия React для Dart. К сожалению, поддержка комьюнити не очень большая, а сам проект разрабатывается в основном компанией Workiva.

Flutter for Web

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

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

Помимо этого, Flutter пока не имеет ряда немаловажных для современного web возможностей, например SSR или SEO.

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

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

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

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

Подробнее..

Перевод Daily Standup пустая трата времени

07.04.2021 16:22:59 | Автор: admin

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

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

Этот формат вроде как работает.

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

Меня не волнует, что ты сделал вчера.

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

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

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

Имеет ли значение daily standup?

Что такое daily standup?

Если вы не знакомы с daily standup, то это ежедневное собрание команды для обсуждения текущего проекта. Оно длится порядка 15 минут и предполагает, что каждый человек отвечает на следующие вопросы:

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

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

  • Какие препятствия мешают мне или команде достичь поставленных целей?

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

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

Проблемы формата Daily Standup

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

  • Я начинаю думать о своем вкладе, чтобы доказать свою полезность;

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

  • Наконец-то настала моя очередь сообщать о проделанной работе. Но никто не слушает, кроме руководителя;

  • Мы выходим за временные рамки и заканчиваем, когда другая команда начинает мельтешить у входа в комнату в ожидании своего daily standup.

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

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

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

  • Больше людей приносят больше нововведений.

  • Больше нововведений больше информации, на которую другим людям будет наплевать.

  • Команда может работать сразу над несколькими проектами.

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

Проще говоря, традиционный формат daily standup не масштабируется.

Масштабируемый формат daily standup: Walk the Board

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

  • Что было сделано вчера?

  • Что запланировано на сегодня?

  • Что мешает команде добиться прогресса?

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

Этот формат работает следующим образом:

  • Создайте доску, на которой будет отображаться статус каждого элемента, над которым работает команда.

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

  • Обязательно спросите: Что нужно, чтобы переместить этот элемент на следующий этап прогресса?

  • Выделите проблемы, мешающие работе.

  • Перейдите к следующему столбцу слева и получите обновления для каждого тикета в этом столбце.

  • Продолжайте, пока не дойдете до самого левого столбца.

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

Теперь может показаться, что этот формат занимает много времени. Но это не так!

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

Что делать, если формат Walk the Board слишком долгий?

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

Если вам нужно обсудить слишком много вещей , стоит подумать, как ваша команда может взять на себя меньше элементов? Как исправить это тема для другого разговора. А пока я рекомендую прочитать книгу Agile Project Management with Kanban.

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

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

Значение играет не сам Daily standup, а время после него.

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

Все в команде общаются.

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

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

Это заставило меня понять, что настоящая ценность daily standup не сама встреча, а время, которое наступает после неё.

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

Заключение

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

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

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

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

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

Подробнее..

YouTrack теперь с центром уведомлений

07.04.2021 20:14:16 | Автор: admin

Привет, Хабр!

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

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

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

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

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

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

Время под контролем: теперь и в YouTrack Lite

В версии 2020.6 мы представили альтернативный интерфейс YouTrack Lite с удобным текстовым редактором и табличным представлением списка задач. Мы получили много положительных отзывов о новом интерфейсе и продолжили его развивать: по просьбам наших пользователей в этой версии мы добавили функции учета времени. Теперь YouTrack Lite позволяет указывать затраченное время и просматривать единицы работы.

Связь с внешним миром: ссылки в строковых полях

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

Поиск полного дерева подзадач

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

Этот синтаксис можно применять не только к типу связи подзадача, но и ко всем типам связи с направленностью объединение, например, к дубликатам (совокупность дубликат: ID задачи)

Иерархия групп

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

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

Дополнительные поля в профилях пользователей

Помимо учетных данных, имен и электронных адресов, в профилях пользователей теперь можно указывать дополнительную информацию например, телефонные номера или должности сотрудников. Рабочие процессы (workflows) YouTrack тоже могут оперировать этими полями. Например, вы сможете разрешить выполнение определенных действий только генеральному директору компании. Кроме того, настраиваемые атрибуты могут быть синхронизированы с AD-сервером (или любым LDAP-сервером) и доступны через REST API Hub, что открывает еще больше возможностей для автоматизации.

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

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

Команда YouTrack

Подробнее..

Organization as a Function. Введение в бережливую разработку для инженеров

08.04.2021 16:21:10 | Автор: admin

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

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

Наша программа правильно выполняла свою задачу: на экране в бешеном темпе курсор прыгал по ячейкам, писал в них формулы, выделял диапазоны данных. Выполнение программы занимало 40 минут, а загруженность процессора была 100%. Мы хотели быстрее. Может быть, надо запустить программу на компьютере помощнее? Или написать распределенную программу и собрать компьютеры в кластер? Любой здравомыслящий программист поймет, что это плохие решения и ускорения можно добиться куда более простыми методами. Мы исследовали причины низкой производительности и обнаружили, что вся проблема была в том, что программа механически повторяла методические указания. Гораздо эффективнее было не повторять поведение человека в Excel, а перенести все данные из таблицы в память, выполнить необходимые расчеты и записать результаты обратно. Новая версия программы работала 50 мс, так мы оптимизировали программу приблизительно в 50000 раз.

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

В производстве подобные приемы были созданы в Toyota и назывались Toyota Production System. Эти приемы были обобщены до бизнеса в целом в виде философии кайдзен. В области разработки программного обеспечения их называют приемами бережливой разработки программного обеспечения.

Согласитесь, как здорово улучшить работу организации в 50 000 раз! Это, конечно, сказки, но и 10% может быть весьма неплохо.

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

Моделируем организацию

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

Прибыль = доходы - расходы

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

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

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

  • Сервис должен надежно и правильно работать. Если он не работает или работает не так, то грош цена всей его функциональности.

Программисты вкладываются в обе составляющие наряду с командами инфраструктуры и DevOps.

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

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

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

Вернемся к аналогии про оптимизацию программного обеспечения.

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

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

Приступим к оптимизации!

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

def joom(market_info, money_from_user):    requirements = product_manager(market_info, money_from_user)    infra = infra_team()    while True:        new_release = product_team(requirements, infra)        if quality_control(new_release, requirements, infra):            service = deploy_to_production(new_features)            return service

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

Удаляем мертвый код

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

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

Взгляните на этот пример

def product_team(requirements, infra):    long_useless_meeting() # what is that for? Let's remove it.    implementation_plan = plan(requirements, infra)    log.debug(implementation_plan) # if logging is fast enough, we can leave it here    return code(implementation_plan, requirements, infra)

Если некоторая деятельность в организации не приводит к профиту пользователя прекратите это делать.

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

  • Если что-то нельзя не делать, то тратьте на это минимум ресурсов.

Реализуем только полезную функциональность

Посмотрим на организацию как функцию еще раз.

def joom(market_info, money_from_user):    # something    return service

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

def test():    service = joom(some_marketing_info, previous_money_from_user)    assert makes_money(service)

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

def profitable_joom(market_info, money_from_user):    while True:        service = joom(market_info, money_from_user)        if makes_money(service)            return service

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

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

def joom(market_info, money_from_user):    requirements = product_manager(market_info, money_from_user)    assert makes_money(requirements) # fail-fast if cannot make money    infra = infra_team()    while True:        new_release = product_team(requirements, infra)        assert makes_money(new_release) # fail-fast if cannot make money        if quality_control(new_release, requirements, infra):            service = deploy_to_production(new_features)            assert makes_money(service) # fail-fast if cannot make money            return service

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

Вопрос для размышления читателю. А что если сама функция makes_money подвержена ошибкам?

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

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

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

  • Реализовали не то, что хотели потери в коммуникации.

  • Реализовали то, что хотели, но оно не работает из-за потерь качества.

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

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

Любой метод выбора правильных идей требует ресурсов и может давать ложные результаты.

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

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

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

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

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

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

def profitable_joom(market_info, money_from_user):    while True:        mvp_service = joom_prototyping(market_info, money_from_user)        if makes_money(mvp_service):            service = joom(market_info, money_from_user)            if makes_money(service)                return service

Это классический метод оптимизации. Например, он широкого распространен в форме double check locking.

Минимизируем бюрократию

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

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

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

def product_team(requirements, infra):    implementation_plan = plan(requirements, infra)    return code(implementation_plan, infra)

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

SCRUM, KanBan, planning poker, недельные отчеты, квартальное планирование, peer review и т.п. все это инструменты повышения продуктивности. Я собирательно назвал их бюрократией, но не вкладываю в это понятие негативную оценку.

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

  • устраняет потери ресурсов из-за недостатка коммуникации,

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

  • мотивирует сотрудников к профессиональному росту,

  • улучшает фокусировку на том, что принесет максимальную пользу,

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

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

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

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

Я работаю в команде Joom Ads, и мы отвечаем за рекламу в маркетплейсе. Когда мы начинали работать над проектом, мы намеренно не делали никакого процесса (AdHoc), но затем, по мере роста команды и сложности разработки, мы стали обращать внимание на потери и адаптировали свои процессы. Сейчас наш процесс эволюционировал в KanBan с continuous delivery, практически все рутинные процессы автоматизированы.

Вопрос для размышления читателю. Чтение этих строк приносит пользу?

Используем эффективные алгоритмы

При написании кода важно использовать эффективные алгоритмы. Лучше использовать алгоритм со сложностью O(NLogN) вместо O(N2). Но если вдруг N небольшое, то никакой практической разницы между этими двумя алгоритмами может не быть, можно воспользоваться алгоритмом со сложностью O(N2), к тому же такие алгоритмы, как правило, проще. Проблемы с таким решением начнутся, если N начнет расти.

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

Например:

def product_team(requirements, infra):    for implemented in already_implemented:        if implemented == requirements:            return None    implementation_plan = plan(requirements, infra)    release = code(implementation_plan, requirements, infra)    already_implemented.append(requirements)    return release

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

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

Управляем техническим долгом

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

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

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

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

Инвестируем в рефакторинг

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

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

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

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

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

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

Инвестируем в библиотеки и инструменты

А как оценить инвестицию не в рефакторинг, а в некоторый инструмент или библиотеку? Стоит ли взять какой-то open source инструмент или написать своё будет продуктивнее? Ведь со сложным open source придется разбираться, это потребует ресурсов, а написать свой инструмент будет даже быстрее.

Главный вопрос при создании велосипедов а что будет дальше?

Пока на написание и поддержку своего инструмента уходит меньше времени, чем на изучение open source, профит точно есть.

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

  • Создание и отладку инструмента. Open source уже прошел этот путь.

  • Поддержку инструмента своими силами. У open source есть community для этого.

  • Написание качественной документации. Про open source могут быть написаны книги, как минимум множество ответов в stackoverflow и т.п.

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

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

Тем не менее создание собственного решения может быть продуктивным.

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

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

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

В ходе разработки JoomAds нам не довелось изобретать велосипеды, мы брали существующие инструменты, порой внося изменения в их код и исправляя баги. К сожалению, некоторые решения пришлось менять. Так, мы не смогли добиться достаточной надежности от Apache Ignite и заменили его на сочетание Apache Cassandra, Apache Kafka и Apache Flink. Как ни странно, решение с большим количеством компонентов в итоге оказалось и проще, и надежнее. Подробнее о нем можно прочитать тут.

Заключение

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

Подробнее..

Про outsource и product компании

10.04.2021 14:17:23 | Автор: admin

Всем привет.

Я team lead, сертифицированный коуч и начинающий психолог.

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

Я работал в двух продуктовых компаниях, одной outstaff (жил и работал в Абу Даби, по контракту с минской компанией) и двух outsource. В общей сложности был где-то на 15 проектах.

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

  • За время работы заметил следующие интересные феномены:

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

  • В продуктовых компаниях меньше менеджмента

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

Ни на одном проекте не встретил аналитику в outsource.

Здесь думаю следует пояснить, что такое outsource.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И здесь есть интересная ловушка.

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

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

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

Для упрощения воспользуемся метафорой семьи.

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

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

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

Здесь очень важно заметить про страх непринятия и обесценивания.

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

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

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

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

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

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

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

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

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

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

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

Такой конфликт спор за признание родителя. Или "про процессы". Является наиболее частым в outsource компании именно из-за специфики работы.

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

От сюда и появляется первый феномен (из начала статьи).

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

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

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

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

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

Подробнее..

Перевод Нет Jira нет проблемы

11.04.2021 12:12:58 | Автор: admin

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

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


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

Но вот что примечательно: Jira преподносит себя как "рабочий инструмент номер один для гибких команд". Гибких? Хм-мм... Если для управления Jira нужен особый человек или даже целая аутсорсинговая компания, о какой гибкости можно говорить?

Давайте разберёмся, что вообще означает термин "гибкий" (Agile) и почему про него все сегодня говорят?

Последовательная разработка

Сегодня только и разговоров, что про методику Agile, как раньше про методику Waterfall. Впервые каскадная методика Waterfall была описана Уинстоном Ройсом в статье, опубликованной в 1970 году. Хотя термин Waterfall (каскад) не был употреблён в статье ни разу, описание метода напомнило многим каскадную схему:

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

Основная идея методики: любое планирование процессов разработки программного обеспечения должно осуществляться заранее, после чего должны выполняться последовательные шаги по созданию и поставке программного обеспечения. Данная концепция отлично вписывается в старые идеи научных методов управления, заложенные Фредериком Уинслоу Тейлором ещё в 1911 году. Если опустить детали, его идея состоит в следующем: организацию работ нельзя доверять исполнителям, нужна отдельная группа людей группа организаторов процесса, которая разработает последовательность действий, после чего безукоснительное выполнение таких действий поручается исполнителям.

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

Встреча в Сноубэрд

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

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

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

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

-Мэри Поппендик

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

Основные положения манифеста:

  • Люди и взаимодействие важнее процессов и инструментов.

  • Работающий продукт важнее исчерпывающей документации.

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

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

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

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

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

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

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

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

Как же так, вообще без процесса?

Но нужен же какой-то процесс, разве нет? Нужен, но какой? Да очень простой использовать всё, что работает! Но как узнать, будет ли он работать? Тут следует применить эвристический подход.

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

Инструменты

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

Инструмент, подходящий под это описание и имеющийся в каждом офисе, уже имеется!

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

Что не так с Jira?

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

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

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

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

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

Другие профессии и курсы
Подробнее..

Пожарный не из Чикаго как тушить огонь в ИТ-проектах

15.04.2021 16:11:54 | Автор: admin

Привет, Хабр! Меня зовут Александр. 17 лет в КРОК. В основном занимаюсь разработкой и внедрением заказного ПО, хранилищ данных, решений Big Data для бизнеса и госсектора. Начинал консультантом по внедрению и последние 11 лет работаю менеджером крупных комплексных проектов. А еще я немного пожарный, потому что регулярно помогаю коллегам тушить проектный огонь.

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

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

Про коллаборацию заказчика и соисполнителей

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

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

Про коллаборацию заказчика и соисполнителей еще раз

Годы работы в проектах ЕМИАС преподносили нам очень разные вызовы в 2013 у нас была команда внедрения с 700+ консультантами во всех амбулаторно-поликлинических учреждениях Москвы. В 2018 нам надо было найти 100+ консультантов для внедрения лабораторного сервиса ЕМИАС это два месяца собеседований нон-стоп. Но оно того стоило!

Как справились с огнем? Тут, опять же, заказчик помогал в согласовании плана внедрения на стороне объектов внедрения с постепенным наращиванием оборотов и административным ресурсом с оповещением поликлиник, лабораторий. Это еще раз подтверждает тезис необходимости совместной мощной команды не только со стороны исполнителя, но и заказчика. В сложных проектах верно выстроенный процесс взаимодействия и коммуникаций (читай синергия команд обеих сторон процесса) путь к успеху. И вторая мораль этой истории не бояться огня. Глаза боятся (осознав, сколько нужно консультантов и в какой срок, задача казалась нерешаемой в принципе), а руки взяли и сделали! Хоть и собеседования проводили всем миром.

Про ток, или Как снять напряженность клиента

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

Как справились с огнем? Здесь была сильная команда со стороны заказчика, и в админ ресурсе не было проблем, но дело шло к проблемам. Мы вовремя круто перевернули ситуацию, когда применили гибкие подходы к разработке. Скоуп сложили в бэклог, расставили совместно с клиентом приоритеты, разбили на спринты (хотя они и были длиной в месяц, тут это было оправдано, поскольку проект шел 1,5 года). В течение спринта раз в две недели проводили статус, уточняли при необходимости постановки, расставляли вместе приоритеты. Плюс раз в месяц с релизом проводили демо и короткую ретроспективу совместно с заказчиком. Это позволило полностью перезагрузить проект, и он заиграл новыми красками. Заказчик начал понимать, что происходит, а потому успокоился, и мы успешно прибежали к финишу с победой.

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

Несколько похожая, но вместе с тем иная ситуация была у меня и в другом проекте, где мы для одного из банков делали Big Data систему для построения профиля клиента и оценки рисков при выдаче кредита. В момент подключения меня в проект была не первая фаза, а я не первым РП на стороне исполнителя. Ситуация была схожа с прошлым кейсом непрозрачный процесс разработки для заказчика усугублялась отсутствием четкого ТЗ, ибо такого рода систем в банке, да и на рынке, в то время по сути еще никто не делал. Были первые ласточки в банке Т и банке А, однако готовых решений (да еще на open source) не было. По сути строили с нуля, склеивая кусочный опыт в комплексное решение, попутно синхронизируясь с заказчиком. И еще требования бизнес-заказчиков ловко и резко менялись по ходу представления.

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

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

Про не всемогущий agile

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

А от исполнителя нужно только локальное управление внутри задач и команды, приоритеты и контроль, состав спринтов. Работали по T&M, еженедельно отгружая таймшиты. При этом нам полностью доверили экспертизу и проектирование системы и ее архитектуры, но на входе дали лишь основную суть бизнес-задачи. Детальное исследование и постановка была тоже на нас. Главная проблема была в том, что кроме РП со стороны заказчика в его команде первые два месяца по сути никого не было. И осознал он (мы заметно раньше) эту проблему только через два месяца работы. То есть когда мы, во-первых, не дошли до ожидаемого им результата (напомню, управление на стороне заказчика) и, во-вторых, ему показалось, что выставленный счет слишком высок, несмотря на регулярные таймшиты, которые принимались и фиксированные ставки договор-то был по T&M. Пахло кризисом жанра. Ситуацию усугубляло еще и то, что со стороны заказчика, как и в прошлом кейсе, системы-источники для разрабатываемой системы были не готовы с нами интегрироваться, а заказчик отказывался принимать результаты работ без демо работоспособного решения.

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

Про опытных пожарных

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

Мало огня?

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

Этот кейс был особенно сложен еще и тем, что по ходу проекта (это более 1,5 лет) многие задачи делались от потребности заказчика в моменте, без оглядки на ТЗ. К концу проекта оказалось, что сделана гигантская работа, но не по ТЗ. Хотя многое реально потеряло актуальность за время проекта. А подписались-то мы под ТЗ. И особенности конкретного заказчика были таковы, что невыполненные требования ТЗ к принимаемой системе это путь под откос.

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

Противопожарные меры

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

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

1. Отсутствие полной команды управления исполнителя. Для КРОК это два менеджера РП и технический менеджер ТМ, а для комплексных проектов с несколькими командами РП и несколько ТМ;

2. Проблемы коммуникаций не пускают к функциональным заказчикам;

3. Проблемы коммуникаций между смежными командами внутри исполнителя (тоже бывает не так уж редко), и, конечно, с командами заказчика;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее..

Практика создания единого шаблона проектов на базе Azure DevOps (TFS)

16.04.2021 08:17:32 | Автор: admin

В одной из прошлых статей мы писали, как всей компанией перешли на единый трекер на базе Azure DevOps (TFS). Это позволило нам создать единый свод правил для ведения проектов. Рассказываем, как наш проектный офис разработал логику, по которой сейчас работают все наши команды.

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

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

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

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

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

Дальше про то, по какой логике работает шаблон и какие настройки в него встроены по умолчанию.

Что входит в шаблон проекта True Engineering

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

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

Здесь важным критерием является конечность эпика во времени, то есть достижимость конкретной цели. Хороший пример эпика Автоматизация тестирования на проекте.

Под ними Feature, эти элементы разрабатываются за 1-3 спринта). Одна Feature один бизнес-сценарий. Например, оформление командировок.

Ещё одним уровнем ниже PBI (Product Backlog Item, единица поставки), они представляют собой отдельный кейс в рамках сценария. Подготовка заявки на командировку, согласование поступающих заявок, загрузка чеков для авансового отчёта это PBI. Они разделяются на Task-и, атомарные единицы работы, которая назначается на исполнителя и не занимает больше 8 часов.

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

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

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

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

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

3. Поддержка планирования ресурсов и времени. Мы внедрили во всех командах три метрики для контроля трудозатрат:

  • Первоначальная оценка времени на разработку

  • Реально зарепорченное время

  • Остаток времени

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

Технические возможности шаблона в Azure DevOps

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

Плагин TFS Aggregator. Этот инструмент подключается к проекту и позволяет автоматические контролировать движение статусов Task-ов и по этим данным отслеживать состояние их родительских PBI. В результате мы можем написать единые правила для трекера заказчика и отправлять ему оповещения о статусах релизов, комментариев к задачам и т.д. Эта функция используется для автоматического сбора Release Notes, уведомления заказчикам о поставках фич, как мы рассказывали в материале про Release Notes.

Интеграция с OLAP-кубом. Эта функциональность отвечает за анализ трудозатрат, статусов задач, контроль Time-to-Market, прочих проектных показателей. Раньше мы использовали куб для контроля показателей внутри проектов. Когда у нас появилась единая система координат, стало возможным делать сквозную аналитику по всем командам сразу мы знаем, что во всех проектах действуют одни и те же измерения с одними и теми же смыслами.

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

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

Куда двигаемся дальше

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

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

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

Подробнее..

Интервью с техдиректором ElectroNeek от написания кода к управлению процессами

13.04.2021 18:11:50 | Автор: admin
image

Я пообщался с основателями стартапа ElectroNeek: Сергеем (CEO), Дмитрием (CIO) и Михаилом (CTO). В конце интервью видео, где в прямом эфире собирают робота.

Дмитрий, пришли, пожалуйста фотку для КДПВ, где вы все вместе.
Не поверишь, мы так вживую и не встретились еще все за два года)

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

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

Что такое робот?

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


Михайл, вас хантил Яндекс, но вы всё же решили работать в ElectroNeek, какая у вас мотивация работать в стартапе, а не на теплом гарантированном месте?

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

Михаил, как тебя схантили?

Михаил:К тому моменту, я уже год как ушел из Акрониса, я перестал видеть свой вектор развития, хотел изучал разные технологии, делал pet-проекты. Мне хотелось делать что-то своё и я искал себе команду. А тем временем Димитрий и Сергей искали себе CTO и кинули клич по своим знакомым. Я был знаком с Дмитрием с университета, хотя особо и не общались, так и сконтачились. Я был готов к этому предложению.

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

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

Я увидел, что спрос есть, как минимум, в России. Дмитрий рассказал о глобальном рынке, в частности про США. Он до этого работал в Ernst & Young и занимался там RPA для Fortune 500 rкомпаний, так что хорошо представлял себе спрос.

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

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

Как выглядел Electroneek до твоего прихода в проект?

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

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

В чем особенность разработки RPA продукта от остальных?

Сергей: Чем отличается разработка RPA-платформы от продукта сам в себе. RPA платформа, в частности ElectroNeek это средство разработки. Средство по созданию чего-то по взаимодействию с чем-то третьим. Это не отдельный продукт как CRM, которая сама в себе и только иногда по API взаимодействует с чем-то третьим.

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

Зачем ещё один RPA-продукт на рынке?

Сергей: часто к нам приходят люди и говорят: Зачем вы разрабатываете, когда можно зайти на какой-нибудь веб сайт, скачать готовый модуль RPA кликера и его делать?. Да он сможет открыть блокнот, освоится с интернет-эксплорером, откроет Гугл. Но как только ты пойдешь дальше (как только появится XPath или селекторы), разные варианты сайтов, государственных или SaaS экосистем, ты столкнешься с тем, что оно не готово и не работает. А дальше, если ты занимаешься развитием собственной платформы, тебе это нужно подстраиваться под изменения, а если всё уже зашито намертво, то ты не можешь гибко подстраиваться к изменениям. Это у нас было на пилоте.

Как выбирали стэк технологий?

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

Мне нужно было обеспечить какую-то многостаночность, чтобы 1-3 человека могли делать всё. Потому мы выбрали Electron. Он позволяет на одном и том же языке (у нас это TypeScript) писать десктопное приложение, backend и frontend.

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

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

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

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

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

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

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

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

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

Я взял стандартную библиотеку на C# UIAvtomation, ею же в тот момент пользовались наши конкуренты. Недавно мы ее заменили на более современную.

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



Как реализовывали фичи?

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

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

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

Мы просто прокликивали это приложение, скрэпили данные оттуда и складывали на диск.

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

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

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

Какой масштаб работы был для почты России?

Михаил: Приложение содержало всех сотрудников Почты России по всей стране. Руками это прокликать невозможно.

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

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

Как привлекали инвестиции?

Михаил: Нам нужен был рабочий прототип, который бы впечатлял инвесторов. Интерфейс решения для Почты России не был красивым, его делал я, а я не дизайнер. Я сделал под себя, IDE WebStorm Dark mode.



Ранние этапы прототипа



ElectroNeek в 2021

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

Что из себя представляли демонстрации инвесторам?

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

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

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

Сергей: У нас были ограниченные ресурсы, мы получили всего 150 000 долларов из них наличными дошло 70 000. Это все что было, чтобы допилить прототип до нормального продукта и показать первые продажи в России и в США. Потом подняли 0,5 млн долларов. Мы показали быстрые продажи. В нас поверили инвесторы.

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

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

Как вы нанимаете разработчиков?

Михаил: Я больше обращаю внимание на способности, а не на опыт. Опыт важен, но разработка дело такое, где постоянно надо чему-то учиться. Когда в проект придётся затащить новую библиотеку, вероятность того, что ты ее знаешь, будет не очень высока. Знания важны базовые. Нам нужно было знание TypeScript, переучивать на другой язык долго. Фреймворк желательно знать. Мы используем от Angular.

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

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

Сколько сейчас людей?

Михаил: Шесть человек ядровая разработка, которые непосредственно платформу делают. Четыре человека, которые на платформе делают переиспользуемые решения. Они используют именно платформу, плюс дополнительные инструменты на скриптовых языках, и делают конкретные проекты. Я сейчас только про разработчиков говорю. Ещё есть отдел QA, отдельно продуктовая команда.

Как ты перешел от написания кода к управленческим обязанностям CTO?

Михаил: После получения инвестиций я ещё несколько месяцев активно писал код. QA мы хоть и наняли, но я в них особо не был уверен. Я сам писал код-ревью.

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

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

Вот вы смирились с падением качества, что дальше?

Михаил: Смотрим, нет у меня больше опции ревьюить код, это мы уже проходили. Что я ещё могу? Теперь можно процессные вещи налаживать.

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

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

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

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

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

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

Чем ты сейчас занимаешься?

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

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

Как ты учишься?

Михаил: Сначала я четко формулирую проблему. Жизненный опыт многое уже позволяет решать. Я уже знаю гораздо больше, чем на момент выпуска из университета, но все равно есть проблемы, которые я не понимаю как решить.
Для начала я разбираюсь в чем проблема. Допустим, у меня нет какого-то инструмента. Гуглю, смотрю YouTube или какой-то курс, выясняю, как делают профессионалы в конкретной области.

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

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

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

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

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

Совет самому себе в молодости?

Михаил: Мне на старте казалось, что сначала надо очень многому научиться. Чего-то я ещё не знаю. Не умею писать веб-сайт, не умею писать бекэнд. Мне хотелось сначала курс какой-то пройти или университет закончить. На самом деле нет. Возьми и попробуй. Гугл отличный инструмент, там вообще все есть. Решай проблемы точечно. Не умеешь конкретно это делать, конкретно это и научись делать. Не умеешь ты nginx настраивать, вот конкретно это и изучи.

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

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

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

Расскажите про Service Organization Controls (SOС)?

Сергей: Если вы хотите делать приложение SaaS на американском рынке, особенно что-то, что будет работать в компаниях больше 200-500 человек, сразу возникнет вопрос про SOC (Security Organization Control). Пока его у тебя нет, все его спрашивают. Это история, которая причесывает политики организации распределение по уровню прав и доступа, как проектировать код, приходят аудиторы, проверяют.

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

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

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

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

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

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

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

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

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

Окей, таким путём мы будем долго идти. А может найдём компанию, которая нам упростит жизнь? Наши компанию. На тот момент мы уже были в Y Combinator. Мы задали этот вопрос ребятам оттуда, нам подсказали выпускников YC, которые автоматизируют эту историю. Услуга не бесплатная, но мы купили у них услугу. Это некоторая админка, в которую ты интегрируешь все свои сервисы. JetSuit, Bitbucket, Gitlab, Jira, AWS, Azure, у кого что. Программа сама изучает, где у тебя какие настройки, и говорит что и где тебе не хватает. Ты точечно исправляешь и автоматом закрываются все пункты, что в этой простыне есть.

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

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

Расскажи про Y Combinator глазами разработчика?

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

Если говорить по результату. Мы получили больше бизнесовых преимуществ. Так же помогли техническими ресурсами и до сих пор помогают. Сделали более правильную инфраструктуру в облаке.

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

Мы закончили YC в марте 2020, закрыли раунд 2,5 млн долларов. Начался существенный рост и команды разработки, и задач.

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

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

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

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

У нас есть UX-продакт-менеджер, технологический продакт-менеджер, у нас есть Head of Engineering, есть CTO, есть CEO как представитель бизнеса. У нас сформирован продуктовый офис, где продукт нарезан на разные части. UX, анализ новых фич, инжиниринг. Мы с Михаилом выполняем роль фасилитаторов в случае приоритезации. Я еще отвечаю за sales-фичи. Дмитрий смотрит на то, как продуктовые фичи транслируются или могут транслироваться в маркетинговые возможности и инструменты, такие как наша глобальная библиотека ботов, созданных клиентами и партнерами.

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

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

Можно ли при помощи вашего робота фармить в компьютерных играх, клики в ютюбе?

Дмитрий: На нашей базе один клиент сделал робота, который включает чайник.

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

Сергей: Была у нас одна история. Клиент купил услугу, а потом написал: Я специально выбрал самую не развитую в ИТ направлении девушку в нашей компании, Олю. И вот Оля смогла с помощью ElectroNeek создать робота. Если Оля смогла, то любой в моей компании сможет. Я у вас покупаю продукт! Это высокий показатель простоты использования. Хотя в основном у нас пользуются разработчики junior или middle уровня. Они получают продукт, в любом стэке (веб, десктоп, есть API или нет), создать приложение (робота?), это свобода, которую дает наш продукт.

Дмитрий: Когда попадает продукт к инвесторам на раннеей стадии, то там историия с Олей повторялась, есть свои Оли среди инвесторов. Были ситуации когда в продукт залезали партнеры топовых американских фондов (Гэри Тэн из Initialized, бывший партнер YC и инвестор в Coinbase и Instacart). Партнер руками начал собирать робота.

Бонус: собираем робота в прямом эфире




Читать еще


Подробнее..

Low-code с точки зрения разработчиков есть ли плюсы для инженеров?

13.04.2021 16:13:10 | Автор: admin

В прошлой статье о low-code в enterprise-решениях я обращался к бизнесу. Однако на Хабре бльшая часть пользователей инженеры (Кэп!), и в комментариях к статье я увидел резонное количество типичных возражений по LCDP (low-code development platforms). И пока те, кто не знает про Эффект Даннинга Крююгера, уже ищут кнопку dislike, давайте разберем наиболее частые заблуждения и мысли.

В этой статье я хочу разобрать наиболее частые заблуждения.

  1. Low-code это использование готовых продуктов.

  2. Под low-code понимают развитые code-first платформы. Кто-то из коллег приводил в пример даже WordPress.

  3. В low-code отсутствует нормальный DevOps (code review, versioning, deploy, etc.), нормальное переиспользование кода и прочие абстракции.

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

  5. Low-code можно не понимать, это какой-то артефакт. Мы продолжим кодить как обычно. Впрочем, некоторые разработчики и про DevOps до сих пор не всё понимают и думают, что это должность. Так что с low-code ситуация не уникальна.

Кратко о состоянии отрасли

Потребность в разработке растёт. Дефицит специалистов в отрасли сейчас легко отследить на примере роста окладов: он опережает рост производительности труда в IT-сфере.

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

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

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

Нет никаких предпосылок к изменению этого тренда. Давайте порассуждаем, сможет ли low-code продолжить его.

Low-code это не философия?

В Рунете каждая статья о low-code заканчивается комментариями о несовершенстве конкретного продукта (продуктов). Отдельно о продуктах поговорим чуть ниже, а для начала предлагаю подумать о концепции low-code в целом.

Философия code-first

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

При этом у разработчиков неизбежно возникают два желания.

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

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

В code-first реализовать эти желания не получается.

Философия low-code

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

  • Являются самодокументируемыми в подавляющем большинстве случаев.

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

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

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

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

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

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

Это справедливо и при использовании готовых LCDP, и при разработке в парадигме low-code.

Low-code путают с развитыми code-first платформами

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

LCDP это такая платформа, в которой всё сделано на базе конструктора, ведь если это не так, рано или поздно поддержание такой платформы перейдёт в code-first.

Я бы обозначил следующие критерии LCDP.

  1. Ядро системы содержит только элементы конструктора и всё, что к нему относится, т. е. вам не придётся применять code-first подход для реализации того, для чего предназначена LCDP.

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

Приведу излюбленные нами примеры.

  • ETL / ESB Talend low-code механизмы для построения интеграций.

  • Mendix, Pega, Appian, OutSystems, Caspio как платформы для создания приложений разного класса.

  • Reify, Builder.io, Bildr для фронта.

  • Из новичков 2021 года Corteza (полностью open-source, Go + Vue.js), Amazon Honeycode.

  • Для игроманов давно ли вы смотрели на Unity и продукты на его основе? Видели ли Construct?

  • Российские ELMA BPM, Creatio (разработка Террасофт) и Comindware, универсальная CUBA Platform, Jmix.

  • Продукты особо крупных вендоров Microsoft Power Apps, Oracle APEX, Salesforce Platform, IBM BAS, SAP BTP.

  • Частично open-source Builder.io (фронт), Bonita, Joget.

Есть и пограничные случаи. Например, Pimcore, которая в части фронта, workflow, моделирования инфомоделей с калькулируемыми полями является по своей сути low-code (с некоторыми оговорками, но это не тема данной статьи). Если же пытаться делать что-то за рамками этого, вы свалитесь в традиционное поддержание монолита.

Или тот же Битрикс. В нём удобно моделировать данные и строить бизнес-процессы, в которые при желании упаковывается PHP-код в low-code стиле (т. е. без длинных инициализаций). Однако огромный объём коробочного функционала, созданного не в LCDP-стиле, и отсутствие развитых инструментов low-code в других частях приводят к традиционному code-first.

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

  • это была не LCDP;

  • это была действительно плохая LCDP (такого сколько угодно);

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

Low-code не содержит традиционных средств контроля, привычных разработчику (code review, deploy)

Это миф. Вы найдёте эти компоненты в подавляющем большинстве платформ. Многие (Mendix, Pega) имеют собственные CI с элементами low-code.

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

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

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

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

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

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

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

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

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

Сдав задачу в виде кода и получив через полгода change request, они сталкиваются со следующим:

  • надо вспомнить, как тут что написано;

  • надо бы отрефакторить код быстро устаревает.

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

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

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

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

Low-code можно не понимать, это какой-то артефакт. Лучше продолжим кодить как обычно

Можно не думать о будущем разработки, если допустить, что:

  • количество задач для разработчиков будет расти не медленнее, чем количество самих разработчиков и субститутов разработки (с учётом повышающейся производительности труда);

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

  • другие типы инвестиций не будут конкурировать с инвестициями в IT.

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

Количество задач для разработчиков будет расти не медленнее, чем количество самих разработчиков и субститутов разработки

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

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

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

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

Что мы видим сейчас?

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

  • В отчётах инвестиционных банков рынок no-code решений (которые являются прямыми субститутами разработки) уже сейчас выглядит примерно так. И если вы посмотрите на этот список, то увидите, что количество продуктов растёт. Наберите в поисковике название любой компании low-code/no-code и вы поймёте, что почти все от российского Сбера до американской Apple думают о том, как существенно повысить производительность труда в разработке.

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

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

Бизнес сможет оплачивать растущие аппетиты разработки и не разорится при этом

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

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

Другие типы инвестиций не будут конкурировать с инвестициями в IT

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

Не станет ли на каком-то этапе стоимость IT столь значимой, что будет автоматически отсекать большую часть новых ныне рентабельных проектов?

В заключение

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

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

Подробнее..

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

06.04.2021 12:11:10 | Автор: admin

Бесплатное хранилище артефактов PackageCloud

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

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

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

Например, огромный список бесплатных сервисов для разработчиков ведётся в репозитории free-for-dev. Список составлен пул-реквестами более 900 участников.

Важно подчеркнуть, что конкретно в этом списке отсутствуют альтернативы на своём хостинге (о них см. ниже). Здесь исключительно онлайновые сервисы, то есть SaaS, PaaS, IaaS.

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

Для примера вот несколько тематических категорий.

Основные облачные провайдеры


Ниже указано, в каком объёме предоставляются бесплатные услуги.

Google Cloud Platform

  • App Engine 28 часов фронтенд-инстансов в день, 9 часов бэкенд-инстансов в день
  • Cloud Firestore 1ГБ места, 50000 чтений, 20000 записей, 20000 удалений в день
  • Compute Engine 1 невытесняемый инстанс f1-micro, 30ГБHDD, 5ГБ для снапшотов (не для всех регионов), сеть 1ГБ из Северной Америки во все регионы (кроме Китая и Аргентины) в месяц
  • Cloud Storage 5ГБ, трафик 1ГБ
  • Cloud Shell веб-терминал Linux и базовая IDE с хранилищем на 5ГБ. Лимит 60 часов в неделю
  • Cloud Pub/Sub 10ГБ сообщений в месяц
  • Cloud Functions 2 млн вызовов в месяц (включая все фоновые и HTTP-вызовы)
  • Cloud Run 2 млн запросов в месяц, 360000гигабайт-секунд памяти, 180000 vCPU-секунд вычислительного времени, трафик 1ГБ в месяц из Северной Америки в другие регионы
  • Google Kubernetes Engine отсутствие платы за управление для одного зонального кластера. Но при этом все узлы оплачиваются по стандартной цене Compute Engine
  • BigQuery 1ТБ запросов в месяц, 10ГБ хранилище на месяц
  • Cloud Build 120 минут сборки в день
  • Cloud Source Repositories до 5 пользователей, хранилище 50ГБ, трафик 50ГБ
  • Полный список бесплатных тарифов Google Cloud

Amazon Web Services

  • Amazon DynamoDB СУБД NoSQL на 25ГБ
  • Amazon Lambda 1млн запросов в месяц
  • Amazon SNS 1млн нотификаций в месяц
  • Amazon Cloudwatch 10 пользовательских метрик и 10 предупреждений
  • Amazon Glacier 10ГБ долговременного хранилища объектов
  • Amazon SQS 1 млн запросов из очереди сообщений
  • Amazon CodeBuild 100 минут сборки в месяц
  • Amazon Code Commit 5 активных пользователей в месяц
  • Amazon Code Pipeline 1 активный конвейер в месяц
  • Полный список бесплатных тарифов AWS

Microsoft Azure

  • Virtual Machines 1 виртуальная машина B1S под Linux, одна B1S под Windows
  • App Service 10 приложений (веб, мобильные или API)
  • Functions 1 млн запросов в месяц
  • DevTest Labs среда разработки и тестирования
  • Active Directory 500000 объектов
  • Active Directory B2C хранилище на 50000 пользователей в месяц
  • Azure DevOps 5 активных пользователей, неограниченные приватные репозитории Git
  • Azure Pipelines 10 бесплатных параллельных задач с неограниченным временем выполнения для опенсорсных проектов под Linux, macOS и Windows
  • Microsoft IoT Hub 8000 сообщений в день
  • Load Balancer 1 бесплатный публичный IP (VIP) с балансировкой нагрузки
  • Notification Hubs 1млн пуш-нотификаций
  • Bandwidth внешний трафик 5ГБ в месяц
  • Cosmos DB 5ГБ хранилище и обеспеченная пропускная способность на 400 RU (реквест-юнитов)
  • Static Web Apps сборка, деплой и хостинг статичных приложений и бессерверных функций, с бесплатным SSL, аутентификацией/авторизацией и пользовательскими доменами
  • Storage хранилище для файлов и блобов на 5ГБ в LRS (locally redundant storage)
  • Cognitive Services AI/ML API (компьютерное зрение, перевод, распознавание лиц, боты...) с бесплатным лимитом использования
  • Cognitive Search сервис индексации текстов и поиск на основе ИИ, бесплатно на 10000 документов
  • Azure Kubernetes Service бесплатное управление кластером Kubernetes (хотя при этом оплачиваются сами виртуальные машины, хранение данных и другие сервисы за пределами бесплатных лимитов)
  • Event Grid 100тыс. операций в месяц
  • Полный список бесплатных тарифов Azure

Oracle Cloud

  • Compute два инстанса VM.Standard.E2.1.Micro 1ГБ RAM
  • Block Volume 2 тома, в сумме 100ГБ (используется для вычислений)
  • Object Storage 10 ГБ
  • Load Balancer 1 инстанс на 10 Мбит/с
  • Databases 2 базы данных, по 20 ГБ каждая
  • Monitoring приём до 500млн точек данных, выдача до 1млрд точек данных
  • Bandwidth внешний трафик 10ТБ в месяц с ограничением скорости 5Мбит/с
  • Notifications 1 млн нотификаций в месяц, 1000 отправленных писем
  • Полный список бесплатных тарифов Oracle Cloud

IBM Cloud

  • Cloud Functions 5 млн выполнений в месяц
  • Object Storage 25ГБ в месяц
  • Cloudant Database хранилище на 1 ГБ
  • Db2 Database хранилище на 100МБ
  • API Connect 50000 вызовов API в месяц
  • Availability Monitoring 3 млн точек данных в месяц
  • Log Analysis анализ логов до 500МБ в сутки
  • Полный список бесплатных тарифов IBM Cloud

Аналитика, статистика, логи


Вот несколько сервисов бесплатной аналитики для мобильных приложений и сайтов. Здесь только бесплатные сторонние сервисы. Многие из них можно использовать вместо скриптов Google Analytics, поскольку GA рассматривается как угроза приватности.

Примечание. Программы self-hosted см. в отдельной категории.

  • AO Analytics бесплатная аналитика для любых сайтов, без ограничений по объёму
  • Indicative платформа аналитики до 50млн событий в месяц
  • Amplitude 1 млн событий в месяц, до 2 приложений
  • GoatCounter опенсорсная платформа веб-аналитики бесплатно для некоммерческого использования или self-hosted версия бесплатно для всех. Позиционируется как более приватная альтернатива коммерческим сервисам Google Analytics и Matomo. Бесплатный лимит 6 месяцев хранения данных и 100тыс. просмотров в месяц.
  • Google Analytics, без комментариев
  • Expensify учёт расходов, контроль личных финансов
  • GetInsights система аналитики без куков, бесплатно до 5000 событий в месяц.
  • Heap автоматический трекинг действий пользователя в iOS или веб-приложениях. Бесплатно до 5000 визитов в месяц
  • Keen разнообразные инструменты для сбора данных, анализа и визуализации. Бесплатно до 50000 событий в месяц
  • Яндекс.Метрика российская альтернатива GA, но не лишённая недостатков последнего (в том числе угроза приватности со стороны материнской корпорации)
  • Mixpanel лимит 100000 пользователей в месяц, неограниченный срок хранения данных


    Mixpanel
  • Moesif аналитика API для REST и GraphQL, бесплатно до 500000 вызовов API в месяц
  • Molasses Флаги функций и A/B-тестирование, бесплатно до 3 окружений по 5 флагов функций в каждом.
  • Optimizely A/B-тестирование, бесплатный стартовый план на 1 сайт, 1 приложение iOS и 1 приложение Android
  • Quantcast новый сервис бесплатной аналитики, запущен в марте 2021 года, лимиты бесплатного тарифа официально не объявлены
  • Sematext бесплатно до 50тыс. действий в месяц, хранение данных 1 день
  • Tableau Developer Program бесплатная версия для разработчиков (предрелизная тестовая версия аналитической платформы)
  • UsabilityHub тестирование юзабилити и эффективности разных вариантов веб-дизайна. Бесплатные тесты до 2 минут
  • Woopra бесплатная платформа аналитики для любых продуктов, до 500тыс. действий в месяц, хранение данных до 90 дней

Другие категории



Эмулятор основных операционных систем в браузере copy.sh

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


Опенсорсные инструменты безопасности


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

Например, в нём есть системы для управления уязвимостями Faraday, Archery Sec, Jackhammer,
Watchdog и OpenVAS, сканер контейнеров trivy, менеджеры конфигурация вроде MGMT, Chef и Puppet, бесплатные системы SIEM (анализ событий в реальном времени и реагирование), VPN, инструменты для улучшения безопасности систем на Linux и Windows (Bastille, JShielder, nixarmor, Zeus (AWS), Docker-bench и др.), защита аутентификации в Linux, чёрные списки IP и доменов, прокси, socks-серверы, HTTP-туннели, FTP-прокси, DNS-прокси, инструменты сетевого и серверного мониторинга, системы для определения вторжений в сеть и на хост (NIDS и HIDS, соответственно), мониторинг и анализ логов, антивирусы, спам-фильтры, симуляторы инфраструктуры, файрволы для веб-приложений, сетевые сканеры, системы форензики (поиск цифровых улик), программы анализа файлов, метаданных, оперативной памяти и многие другие инструменты.

Всё бесплатно и с открытыми исходниками.

Бесплатные альтернативы на своём хостинге


Вышеупомянутый список free-for-dev не включает бесплатные инструменты на своём хостинге. Однако их очень много. Обычно это опенсорсные программы. Бывает, что какой-то коммерческий сервис SaaS одновременно публикует исходники, то есть предлагает параллельно платный и бесплатный тариф.

Вот список бесплатных альтернатив на своём хостинге в 81 категории из коллекции awesome-selfhosted:



Списки бесплатных ресурсов для разработчиков также ведутся в проектах FOSS-for-Dev, getAwesomeness и De-google-ify Internet.

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



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

Подробнее..

Завал в IT-компании и как с ним бороться

05.04.2021 08:09:25 | Автор: admin

Работа в режиме завала и в режиме нарастающего завала.

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

Логичным чем-то считается варианта два:

  1. Останавливаем конвейер и все дружно разгребаем завал.

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

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

А что, если идём по второму пути? Правильно!

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

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

Переведем завод на типичную компанию, предоставляющую IT-услуги:

Конвейер - это отлаженная цепь от хотелки до какой-то крутой штуки для заказчика.

Участки (самая длинная возможная цепочка):

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

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

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

  4. Аналитик - когда есть, когда нету, но нужный человек в таком производстве. Он может также находится на участке 2-3 как человек, который превратит потребность Случайного генератора идей в оформленную задачу и вовремя сказать клиенту Вася, ты болван! Давай думать, а не выдумывать или же может играть роль человека, который скажет вот вам кнопка, давайте проверим так ли хорошо. Такого человека можно назвать технолог на производстве и креативный упаковщик одновременно.

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

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

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

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

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

  4. Аналитик. Завал потребностей к постановке и завал задач к сдаче. Он бедняга просто проверять не успевает, его то на первый участок дёрнут, то на третьем не всё понятно, то второй придёт с криками, что надо ему помочь он рвётся, то пятый кричит, что он не так хотел (а ты ему говорил блин!) К чему приводит? К сдвигам сроков программистов и нарушению их горизонта планирования, к уплотнению встреч для сдачи работ клиенту, соответственно теряется время на вникание в потребности и отсев неадекватных задач, теряется время на упаковку кнопки и её заменяют на вот вам, пошарьтесь сами, вроде то, а если заказчика оставить наедине, то это 99% возврат и прочие проблемы этого типа.

  5. Клиент на пятом участке. А ему просто лень вникнуть прям сейчас, он вникнет когда пригодится, если его вовремя четвёртый участок не дернет. К чему приводит? К ах вы бестолочи, я вас просил еще месяц назад и говорил, что мне срочно надо, а вы уже месяц сделать нормально не можете, я из-за вас от генерального получил по шее и по карману и возврату на участок #3. Теперь понимая возможные завалы подведём итог: Конвейер всегда двигается дальше и чем дальше он двигается тем ближе мы к следующему участку, кто-то создал завал - больше давят обстоятельства в виде того что надо подготовить деталь к следующему участку хотя бы как то и то что следующую деталь надо еще быстрее делать..и так по кругу Особенность сферы IT что почти каждая деталь уникальна и выработать механические действия нельзя, соответственно допустить завал на участке 3 не просто вредно, а критично для всех.

Итак выводы со всей болтовни такие:

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

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

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

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

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

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

Вот такие размышления были в моей голове. Жду от вас обратной связи. Слава Хейтерам.

Подробнее..

Быть тимлидом, ч2 Технологии

13.04.2021 12:15:42 | Автор: admin

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


Об уровне владения технологиями



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


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


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


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

Должен ли тимлид постоянно писать код?


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



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


  • инженерная культура;
  • Agile-процессы;
  • SLA;
  • постоянное улучшение качества.

Что я понимаю под инженерной культурой?


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


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


  • архитектурные стандарты;
  • типовые решения;
  • правила оформления кода (stylе guides);
  • стандарты code-review;
  • автомацизация рутинных операций;
  • практики сообщества;
  • работа с техдолгом;
  • документация.

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


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

Agile-процессы


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


Почему налаживание процессов проблема тимлида? Я уверен, что невозможно выпускать стабильный продукт вовремя без налаженных процессов в разработке. Как мы передаём задачи от продукта в разработку? Как проверяем гипотезы? Как уменьшаем риски вкладывания наших усилий не туда? Как релизим? Как даём быструю обратную связь заказчику? Если на эти вопросы не будет чётких ответов, на каждом этапе разработки будут потери времени и усилий на их прояснение. Поэтому, процессы должны сидеть в подкорке мозга каждого члена команды, включая бизнес, дизайн, разработку. И работа тимлида как раз состоит в том, чтобы эти процессы наладить и закрепить. Для этого хорошо подойдёт cookbook свод правил, который стоит обсудить со всеми членами команды и выложить на Confluence/вики/базу знаний команды, показывать новым членам команды при введении в работу, и постоянно совершенствовать его.


SLA


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



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


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

Мониторинг сервисов


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


Архитектурная схема


Когда я говорю архитектурная схема, я не имею в виду чертёж размером со стену, распечатанный на листах А1 (доводилось видеть и такое). Я, скорее, подразумеваю, что тимлид должен знать все компоненты (микросервисы) в своём владении, бизнес-логику, по которой эти компоненты обмениваются данными, типовые сценарии использования сервиса. Также тимлиду нужно знать путь запроса до приложения со всеми балансировщиками, API-гейтвеями, waf-ами, IPS-ками, ингрессами и прочими проксями это позволит быстро диагностировать проблему и найти ответственных.


Настроенный доступ


Даже при хорошо налаженной схеме дежурства может случиться так, что дежурный недоступен (сел телефон, отключили интернет, крепко спит и т.д.). И в таком случае всё равно реагировать придётся тимлиду. Поэтому важно иметь настроенный доступ во все критические системы, которые могут пригодиться при диагностировании и решении проблемы. Для меня это реплики баз данных, поды Kubernetes/kubectl, ELK, CI/CD, UI RabbitMQ, и конечно VPN, чтобы добраться до всего этого.


Отношения со смежниками


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


Постоянное улучшение качества


Не секрет, что в погоне за time-to-market мы часто принимаем быстрые решения и встраиваем костыли в наш код (конечно же, с намерением вернуться и всё отрефакторить, когда будет время!).



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


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


Заключение


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

Подробнее..

Айтишная субстанция

14.04.2021 08:08:47 | Автор: admin

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

Не бойся ошибаться, но работай над ошибками.

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

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

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

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

Докапывайся до причин.

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

Скажете: полноте, так не бывает! Отвечу: а вы сами не наблюдали, как после саморассоса проблемы на неё забивают? Технарям лень, менеджмент не выделяет времени (так заработало же!), причина не установлена, никаких выводов не сделано.
Что нужно делать: отложить все остальные дела, и заниматься только поиском источника странного поведения.

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

Ну а дальше понятно: то ли сработал триггер принудительного обновления кеша, то ли Redis перезапустили без восстановления состояния не суть важно. Ежедневные дампы БД всё-таки были но пользы от них уже не было.

Не лезь в IT за деньгами (оно тебя сожрёт).

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

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

Люби критику.

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

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

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

Не работай в изменённом состоянии сознания.

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

Запустив chown под рутом, разработчик увидел неожиданно большой вывод в терминале, и тут же нажал ctrl+c, отменяя выполнение. Но было уже поздно: он опечатался в пути исполнения, вместо каталога приложения задав команде путь от корня. Это практически порушило систему; чтобы всё продолжило хоть как-то работать, пришлось тут же выдать всем объектам 777, и потом уже муторно восстанавливать руками и скриптами.

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

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

Дороже своего времени только время коллег.

Обычный диалог в чате плохой команды:

@username, мне нужно узнать, как сделать X, это твоя тема.
[Через пять минут]
Ау, @username?!
[проходит несколько часов, перемежаемых кидаемыми в чат смешнявками из тематических каналов]
Хай! Ещё надо?
[Нет, я час ждал ответа, не дождался, потратил два часа на самостоятельное разбирательство, хотя ты мог дать мне нужные данные за пять минут, потерял контекст выполняемых задач, и, в общем, профукал день. И это не в первый раз так. Когда ты обратишься ко мне, я тоже не буду торопиться!]
Уже нет, спасибо...

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

Как должен выглядеть диалог в хорошей команде:

@username, мне нужно узнать, как сделать X, это твоя тема.
Ок, смотри туда-то, там краткая дока для себя. Если нужны будут подробности у меня окошко через два часа, можем созвон.
Отлично, спасибо!

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

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

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

Будь учёным.

К сожалению, обучение на айтишника обычно сводится к вот этому:

Баянистый баян из страны баянов

ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ ПОСЛЕДНИЕ 9 КЛАССОВ. ВОТ БЕЙСИК, ОН РЕШАЕТ!
@
ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ В ШКОЛЕ, ВОТ ПАСКАЛЬ, ОН РЕШАЕТ!
@
ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ НА ПЕРВОМ КУРСЕ, ВОТ АСМ, ОН РЕШАЕТ!
@
ЗАБУДЬТЕ ВСЕ ЧЕМУ ВАС УЧИЛИ, ВОТ ДИПЛОМ ПО СИШАРПУ, РЕШАЙТЕ.
@
ЗАБУДЬТЕ ВСЕ, ЧЕМУ ВАС УЧИЛИ В ВУЗЕ, ВОТ ПОХАПЕ, ЗДЕЛАЙТИ НАМ САЙТ ПОЖАЛСТА

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

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

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

Stay calm.

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

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

Спорт необходим.

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

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

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

Комментируй это.

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

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

Не треплись много, треплись мало.

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

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

Ну я делал фичу X, там надо было вот это так, но я решил сделать это так, и

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

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

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

Делай бекапы!

Точно сделал? А если подумать? Автоматические? Инкрементные? На другую физическую машину? А лучше, конечно, на две. А восстановление проверил?

Вот казалось бы, сколько лет твердят: резервируй и перерезервируй но сколько твердят, столько я и натыкаюсь на игнорирование этого правила. Последний раз совсем недавно: бекапы боевой БД то ли не делались, то ли делались на другой раздел той же виртуалки; админский скрипт, удаляющий бесхозные инстансы чпокнул сервер (почему так получилось отдельный разговор). Хоть какие-то данные пришлось выковыривать с dev-окружения, естественно, с потерями и искажениями, не говоря уж о простое сервиса. А ситуацию мог спасти трёхстрочный скрипт, раз в сутки архивирующий дамп, и отправляющий его да хоть по почте, если уж совсем больше некуда.

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

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

Очень болезненное наблюдение: мало кто умеет пользоваться тулзами и окружением, с которыми работают. Примеры очевидны: от запуска команд с sudo по умолчанию (т.е. пользователь не понимает идею разделения привилегий и ни разу не натыкался на патч Бармина) до использования VCS в качестве помойки.

Собственно, помойка в гите (сто тысяч устаревших серверных веток, мусорные commit message, не относящиеся к делу файлы) это погань, от которой лид команды должен отучивать разработчиков. А за форс пуши уже и наказывать: как правило, форс пуш применяется неопытным разработчиком, как универсальное решение какой-то проблемы, с которой нормально справиться он не смог. Не порешал конфликты при мерже, например, испугался и перезатёр файлик локальным бекапом (он-то по старинке версионируется каталогами!). Беда тут в том, что с гитом работает вся команда, и один косяк может создать проблемы всем сразу.
Хуже ситуации с одним разработчиком, не умеющим в git, только когда в него не умеют все. И всем плевать. И конфиги хранятся в гите, и деплой делается ручками, и тысяча веток на сервере, и хардпуши сразу в мастер, и прочее, и прочее. Видел и вижу такое, к большому сожалению, очень часто.

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

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

Подробнее..

Пройти собеседование и не умереть. От смеха

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

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

Хотя в 99% случаев меня зовут на позицию фронтендера, на собеседовании меня спрашивали совершенно разные вещи: бэкенд, devops, базы данных, сети и администрирование, project management, аналитику, юнит/авто тесты, алгоритмы, парадигмы программирования, криптографию, проверяли английский, давали тесты на IQ и даже устраивали стресс-интервью.

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

Форма скиллов

Бывает, что ты проходишь собеседование на фронтендера, а там задают вопросы не связанные или слабо связанные с ним:

  • Что такое DNS?

  • Что происходит, когда пользователь набирает в браузере адрес сайта?

  • Как расшифровывается SOLID?

  • Чем абстрактный класс отличается от интерфейса?

  • Как реализован алгоритм шифрования?

  • Как оптимизировать SQL-запросы?

  • Чем PATCH отличается от PUT?

Причины не релевантных вопросов:

  1. Нужен человек-оркестр

  2. Интервьюер проверяет форму скиллов

  3. Интервьюер плохо разбирается во фронтенде

  4. Ты не понравился интервьюеру

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

Интервьюер проверяет форму скиллов

Во-втором случае интервьюер пытается прощупать, имеешь ли ты T-shaped или I-shaped skills. T-shaped - это узкая специализация в 1 сфере и поверхностное понимание других. I-shaped - это экспертиза в одной технологии при отсутствии навыков в других.

Такую терминологию впервые предложил David Guest в 1991. Идея была одобрена Тимом Брауном после анализа резюме сотен кандидатов. Второй пункт отличается от первого тем, что у работника есть основная специализация, по которой он будет работать 80-90% времени.

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

Интервьюер плохо разбирается во фронтенде

Третья ситуация встречается там, где отдел только набирается или просто нет опытных фронтендедеров, собеседованием занимается бэкендер. Ему проще спросить то, что он знает: ООП, паттерны, базы данных, сети, сетевая модель OSI.

Ты не понравился интервьюеру

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

Боюсь, что меня унизят на интервью

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

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

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

Ходить ли на вакансии не по стэку?

Конечно, ходить. Можно поставить себе "junior python dev" будучи "senior java dev" и с интересом понаблюдать за требованиями на других языках/стэках/фреймворках. Делать так лучше, если есть небольшой опыт в новом языке, например, в личных проектах или на работе. Это станет новым опытом, хорошей эмоциональной растяжкой и позволит тебе лучше оценить свои навыки. Возможно ты захочешь сменить стэк.

Резюмируя

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

Подробнее..

Категории

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

© 2006-2021, personeltest.ru