xpinjection

2021-05-14 17:00:08 ​​Пятничный развлекательный пост про требования и постановку задач. Все наверняка знают историю про 7 красных линий (или будет повод погуглить). А вот эта встретилась мне только недавно:

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

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

Ну и решение конечно же есть!

#юмор #пятница Открыть/Комментировать

2021-05-13 17:49:00 ​​#реклама

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

Блокчейн — это уже давно не только про криптовалюту и майнинг.

Сегодня технологию используют такие гиганты, как Google, Microsoft, Amazon, Visa, Mastercard, Oracle, IBM. Компании по всему миру выбирают блокчейн, чтобы создавать надежные распределенные хранилища данных. И количество вакансий, связанных со знанием этой технологии, растет с каждым днем.

Хотите узнать больше и сделать первый шаг к профессии будущего? Тогда приходите на интенсив «Как работает блокчейн» от GeekBrains.

Вы узнаете:

Что такое блокчейн.
Как посмотреть транзакции в блокчейне.
Где применяют блокчейн.

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

Записывайтесь → https://gb.ru/link/TA~-4F Открыть/Комментировать

2021-05-10 10:00:31 К завершению отпуска готов поделиться отзывом ещё об одной книге. Не знаю откуда она появилась у меня в списке на чтение и почему попала в топ. Видимо, кто-то сильно рекомендовал. Книга называется «Давай больше не ссориться» авторства Мишель Броди.

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

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

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

#книги #books Открыть/Комментировать

2021-05-09 10:00:33 Продолжаем рассматривать иерархии менеджмента в разработке. Ситуация начинает ухудшаться с необходимостью масштабировать разработку. В оптимальной структуре мы по-прежнему имеем роли PO и SA/TL, а все команды представляют собой самоуправляемые ячейки. Из моего опыта 3-5 команд могут легко работать по такой схеме, 5-8 уже тяжелее, больше 8 уже становится сложно. Что делают в этом случае большинство компаний? Они начинают растить иерархию менеджмента. Появляются новые роли:

7. Delivery Manager (DM), который отвечает за организацию работы нескольких команд (обычно от 2 до 5). Под ним уже находятся PM-ы или Team Lead-ы.

8. Delivery Director (DD) или Program Manager (PGM), который отвечает за организацию работы большого количества команд (обычно от 5 до 10+). Под ним находятся DM-ы.

Вот мы и построили «прекрасную» иерархию PO->DD->DM->PM/TL/SM, в которой очень быстро происходит бюрократизация процессов принятия решений и все замедляется. Для компенсации потери скорости добавляют ещё команд и все ещё больше усугубляется...

Что делать? Есть несколько альтернатив:

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

В первом случае структуру можно оставить максимально плоской, но обычно сложно выделить больше чем 2-3 подпродукта. Во втором и третьем могут понадобиться вспомогательные роли как Stream Lead или Domain Owner для организации работы в рамках стрима или гармоничного развития домена.

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

Избегайте иерархий, за ними редко скрывается что-то хорошее!

#менеджмент #разработка Открыть/Комментировать

2021-05-08 14:57:58 Многие знают про проблему middle management. Она появляется когда создаётся искусственная иерархия менеджмента, в которой начинают тонуть любые решения, идущие сверху вниз или снизу вверх. Эдакий бюрократический амортизатор компании, целью которого является сбережение текущего статуса кво и своей позиции.

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

1. Product Owner (PO) - лидер и драйвер со стороны бизнеса, который отвечает за продуктовую визию, наполнение бэклога, управление приоритетами и развитие продукта.

2. Solution Architect (SA) или Technical Lead (TL), который будет драйвить техническую сторону продукта, включая архитектуру, процессы разработки, инженерные практики и другие технические вопросы.

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

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

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

5. Если нет возможности или желания нанять зрелых специалистов для построения самоорганизованной команды, а SA/TL не имеет опыта управления командой разработки, то на сцене появляется Project Manager, который берёт на себя данную задачу. Альтернативным вариантом на данном этапе является выделение роли Team Lead.

6. Если разработка ведётся по Scrum и в команде ни у кого нет нужного опыта и желания, то на сцене может появиться роль ScrumMaster (SM).

Последние 2 роли практически закрывают собой несовершенство организации, возникающее от недостатка денег, опыта или времени на построение оптимальной структуры. Это первый шаг к созданию сложной иерархической структуры, в которой PO, SA/TL, PM/TL и SM начинают делить области ответственности и влияния. А баланс этого деления будет сильно зависеть от их уровня квалификации и лидерских качеств. Могут получиться очень плохие перекосы, когда за приоритеты начинает отвечать PM или SM становится менеджером команды.

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

#менеджмент #разработка Открыть/Комментировать

2021-05-05 13:16:29 В отпуске с книгами дело движется активнее. Есть свободное время и нетехническая литература быстрее читается. Следующей прочитанной книгой стала «Ловушки мышления» про то, как принимать осознанные решения, о которых не придётся жалеть.

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

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

#books #книги Открыть/Комментировать

2021-05-04 12:13:56 Часто при внедрении автоматизации тестирования в уже существующий процесс разработки (когда она не закладывалась изначально как часть этого процесса) люди задумываются над метриками эффективности внедрения. И тут быстро становится понятно, что одним покрытием кода сыт не будешь. Для подсчета ROI автоматизации нужно понимать сколько времени сэкономлено, находятся ли реальные дефекты, какова стоимость поддержки тестов в актуальном состоянии и насколько они надёжны.

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

А вы что измеряете в области автоматизации тестирования?

#qa #качество Открыть/Комментировать

2021-04-30 11:37:20 Я дочитал очередную техническую книгу, пришло время обзора. В этот раз она была на тему современной инфраструктуры и архитектуры - «Kubernetes Best Practices». Когда я добавлял эту книгу в список для чтения, меня подкупило название. Ведь достаточно много книг, описывающих основы для старта, но мало сфокусированных на полезном практическом опыте и выученных уроках.

Начнём с плюсов:

- книга достаточно компактная, всего 250 страниц, очень легко читается;
- главы неплохо структурированы и практически не связаны, поэтому можно читать точечно по мере надобности;
- затронуты практически все аспекты работы с Kubernetes от построения кластеров до организации Continuous Delivery.

А теперь про минусы:

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

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

#книги #books Открыть/Комментировать

2021-04-29 10:00:25 #реклама #полезные_каналы

Больше половины продуктов проваливается — команды не могут создать ценность (или найти заветный product/market fit). Но если это произошло, наступает фаза роста. А для нее нужны деньги. А значит придется идти к инвесторам.

Кому дают деньги, а кому — нет? Попросим рассказать об этом Андрея Торбичева, партнера инвестиционного фонда Месторождение (группа ТилТех), автора канала Индекс дятла.
------------------------------------------------------------

“Сколько евреев - столько и мнений”, — говорилось в старом анекдоте. С инвесторами похожая ситуация — у каждого свой подход и инструменты оценки. И все же есть несколько вещей, на которые смотрят все:

1. Рынок. “Главное - правильно выбрать стол”, — говорил Тони Шей, основатель Zappos. Если потребителей мало — неважно, насколько круто выстроен ваш продукт. Он просто не сможет расти. И да, если вы показываете нишевое решение — придется убедительно объяснить, как сможете выйти из ниши. В России интересны рынки, где есть хотя бы 10 млрд.+ рублей.

2. Конкуренты и преимущество. Если есть рынок — значит есть и конкуренты. У кого вы будете отбирать клиентов и за счет чего — вот два вопроса, которые волнуют инвесторов. Обычно мы видим таблички с кучей галочек, где приводятся сравнения разных решений. Лучше выбрать трёх главных конкурентов и выделить ОДНО, но сильное преимущество перед ними.

3. Ключевая метрика. По опыту, рост — следствие фокуса на одной ключевой метрике. Это может быть стоимость привлечения, retention, k-фактор и т.д. Странно, большинство фаундеров и продакт оунеров не знают ее и растят все по чуть-чуть.

4. Команда. Есть человек-продукт и человек-продажи (Hacker и Hustler). То, что называют минимально жизнеспособной командой. Инвестировать в команды, где нет этих двух компетенций — опасно.

5. Стратегия. Это ответ на вопрос, на что конкретно пойдут деньги. Я часто слышу фразы типа “на доработку продукта” или “на рекламу”. И это не лучший способ объяснить инвестору будущий рост.

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

В своем канале @dindex Андрей делится наблюдениями о запуске продуктов/стартапов, поиске ценности и роста, командах и привлечении инвестиций. Кратко и без воды. Подписывайтесь! Открыть/Комментировать

2021-04-27 19:18:20 Меня часто спрашивают про мое видение современного тест менеджмента: какие инструменты использовать, какой формат выбрать, как интегрировать автоматизацию, генерировать отчеты о тестировании и т.д. Последние несколько лет я являюсь активным сторонником подхода «everything as a code» и всячески его пропагандирую не только для инфраструктуры, где это уже давно стало стандартом.

Мы уже внедрили «test cases as a code» для нескольких продвинутых клиентов (очень жаль, что не для всех) и оно работает просто отлично. Сразу в арсенале появляются все привычные разработчикам инструменты для отчетности, интеграций с чем угодно и возможности расширения под свои нужды. И такой тест менеджмент сразу automation native, что делает его на порядок более привлекательным.

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

#qa #тестирование #качество



Открыть/Комментировать