Нововведения за все хорошее и против всего плохого.

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

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

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

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

Вторая встреча техдирского клуба. В этот раз с Андреем Гусевым!

Александр Благодаренко спрашивает: а кому из этих котиков выплатишь премию ты ? 😅

@kathrin_petrova приглашает: отдохнуть от холиваров и послушать вечером немного менеджерских разговорчиков, что может быть лучше?

Пишем выпуск про Servant Leadership с Артемом Каличкиным из ЦФТ, присоединяйтесь к эфиру!

https://www.facebook.com/podlodkacast/videos/309749169910838/

* * Рекламный пост * * Пост проплачен * *

Всем привет!
Приглашаем на AWS Dev Day Moscow от Amazon Web Services и Provectus!

Что будет на конференции?
#AWSDevDayMoscow — бесплатная однодневная техническая конференция из глобальной серии AWS Dev Days, где начинающие инженеры смогут узнать больше о самых актуальных темах облачных технологий этого года, а опытные специалисты — углубиться в знания AWS сервисов.


Что делает AWS Dev Day таким особенным?
💬 10 сильных технических специалистов, готовых делиться своими знаниями
☁️ 2 потока про облачные технологии и сервисы AWS
💡«Ask an AWS Architect», где у участников будет шанс пообщаться с AWS архитекторами 1:1 и обсудить свои проекты

Нас ждут такие доклады как:
* "Machine learning with Amazon SageMaker",
* "Containers CI/CD Pipeline on AWS",
* "Service Mesh Magic",
* "Everything as a Code": 2 года с AWS ECS в production”,
* “Best practices for integrating Amazon Rekognition into your own applications”
... и не только!

Когда? Вторник, 18 июня | 9:00 - 17:00
Где? Пространство “Весна”, Спартаковский переулок 2с1, подъезд №7

Участие бесплатное по предварительной регистрации.
👉 Регистрация на AWS Dev Day: bit.ly/2F8BsjW

📌 Подробнее: awsdevday.moscow.provectus.com
До встречи на AWS Dev Day Moscow!

​​Таинство, колдуны и бизнес

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

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

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

Так и общаются друг с другом.

​​Как не сдохнуть на разработке мобильного приложения

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

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

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


Как с этим жить?

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

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

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

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

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

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

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

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

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

На уровне архитектуры важно воспринимать всю массу работающих приложений целиком, как неотъемлемую часть системы.

Почему так важна открытость в общении команды

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

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

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

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

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

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

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

Рекламный пост Пост проплачен  

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

Как вы думаете, что движет бывших инженеров идти в менеджмент?

Вот, например, компания Флант ищет сейчас технических менеджеров, шарящих в Linux. Даже лонгрид нефиговый запилили:

http://job.flant.ru/manager

Кстати, просили репостнуть. Говорят, у них хорошо :)

Знания - сила

@sloneus задал все заковыристый вопрос:
===

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

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

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

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

Во втором - вы получаете бабло и компенсацию. 

Кейс - полностью рабочий, проверен этой осенью. 

===

А что выберете вы?

Коллеги! Тут у меня спрашивают рекомендации на DataMonsters. Может есть кому что-то в личку мне шепнуть: @ctodsimonov ? Заранее спасибо 🙏

Разные команды, с которыми работает техдир

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

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

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

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

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

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

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

Фуллстек-разработчик
(представитель семейства специалистов по всему)

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

Фуллстек-разработчик обладает магическими способностями: имеет бездонную память, ибо знает все современные языки и технологии; в мозг интегрирован глобальный понятийный аппарат, превосходящий по организации мыслительного процесса Владимира Ленина, Альберта Эйнштейна и Леонардо да Винчи; системное мышление такого специалиста способно производить дебаг чего угодно прямо в мозгу, без применения средств отладки. Неприхотлив, питается солнечным светом.

Высшей формой развития фуллстека является техдир, о котором мечтает любой работодатель: прийдёт мальчик и сделает ФСЁ!

(с) https://habr.com/ru/post/457618/

​​Кратко о том, чем женщина руководитель отличается от мужчины

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

2. Женщины - прирожденные тактики. Можно условно сравнить с ближним и дальним светом, - так вот женская история про ближний свет. Выбирая между журавлем в небе и синицей в руке, как правило, женщины выбирают синицу.

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

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

​​Классическое ТЗ на разработку сервиса (бюджетная статья расходов: канцелярия)