Секретный ингредиент для Дурова

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

VKPay Дуровым в свое время запустить не удалось, направление было открыто только после их ухода; платный ресурс с резюме и вакансиями не стартовал. Телеграм как проект находится в минусе, с Payment API в Телеграме в общем-то повторяется история с VK Pay. TON откладывается на год, как мы знаем.

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

Интересно, какого именно слагаемого, какого секретного ингредиента не хватает гениальным олимпиадникам, чтобы делать операционно-безубыточные сервисы?

Da log

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

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

С тех пор об этом туле тишина в паблике, но я не удивлюсь, если их ресерч-подразделение эту информацию при помощи тула собирает и передаёт во внутренние talent acquisition subsidiaries.

Пост про один из аспектов управления agile-командой (https://t.me/architect_says/329) поднял некоторые вопросы, которые заслуживают рассмотрения. Вот они:

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

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

Q. Но это же жуткий контроль вместо обещанной самоуправляемости?
A. Да, это контроль, и нет, это не разрушает самоуправляемость.
В целом, прежде чем пользоваться советом из чужого манифеста, необходимо найти доказательства, что совет работает. Если в манифесте написано что-то правильное, это не означает что все пункты правильны. Идея о том, что чем меньше контроля — тем лучше, пока не подтверждается никакими массовыми исследованиями. Мало того, социологические исследования показывают, что даже намек на слежку повышает честность, улучшает сборы на благотворительность, и даже продвигает сотрудничество. Наилучший результат дает выборочная проверка результата; именно это и происходит в течение нескольких последовательных итераций. Если результата нет -- пора принять меры.

Q. Почему бы команде не осуществлять контроль самостоятельно?
A. Перспектива контролировать и оценивать своих коллег радует далеко не всех. Многие предпочтут сохранить хорошие отношения с коллегами, нежели акцентировать внимание на пробелах в их работе. Эти же сотрудники хотят «просто хорошо делать свою работу с 9 до 6». В "бирюзовой" парадигме таких сотрудников обычно называют "не вовлеченными" и предлагают их заменить. Да, SCRUM это потогонка, и многие разработчики ВНЕЗАПНО обнаруживают, что самоуправление это не только возможность делать, как хочется, а большой пласт работы, для которого криьтично наличие пресловутых soft skills

Q. Зачем лезть в команду и рассказывать, кто тянет, кто не тянет, кто лидер, а кто нет?
A. Во-первых, см. ответ на предыдущий вопрос, во-вторых, нет никаких доказательств, что группа выбирает наиболее достойного лидера (см. "Популизм"), а превращать группу в команду надо было сильно заранее.

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

* #vacancy *#vacancy *


Господа и дамы, у меня есть свободная вакансия системного аналитика в молодую компанию, откуда спустя полгода-год люди вырастают и уходят на 1.5х-2х зарплаты в крупные компании-лидеры.

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

Если кого-то заинтересовало, пишите в личные сообщения с резюме.

Про опционы

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

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

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

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

А без этого никак.

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

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

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

Является ли проблема оверинжиниринга главной проблемой современной разработки? Я не знаю. Мне кажется, что нет.

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

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

Понятно, что вопрос логичный, правильный, а вот что они хотят узнать, каждый раз не до конца ясно. Потоки и хранилища данных? Технологии? Где и как развернуто? На что опираемся, кому платим? Структурные части и функции в составе? Если структурные, то почему функциональные не очень интересны. Если функциональные, точно готовы альбом на 100+ функций рассматривать?

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

Про дайверсити (выдернул из чата)

Дайверсити это вообще не тема cultural fit, хоть так это и показывают.

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

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

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

Думаете, я тут вам рационализирую? Да нет, вот автор_ка из фонда Golden Seeds, который специализируется на инвестициях в компании, где в c-level женщины, проговорилась и пишет: "если в команде есть хотя бы одна женщина, деньги, полученные от венчурного фонда, тратятся на 63% успешнее. Компании с женщинами в руководстве вырастают быстрее и задействуют на 45% меньше вложений". Не будем придираться к точности цифр и формулировкам, суть важнее.

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

Все заслуживают успеха, в разносторонности наша сила. "Наша", ага.

Идешь мусор вынести, а там уже беседуют про React или k8s

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

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

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

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

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

Если удаленная работа это не намного менее эффективно, и найти удаленного сотрудника проще и дешевле по всему миру, зачем компании Долины тащат своих разработчиков туда и платят им за это х2-х3 ценник?

Гляжу на курсы и мероприятия, и вижу, как в ИТ в РФ возникло некоторое мнение, что главное -- это гипотез навалить, а дальше оно как-то само. Управление проектами? Управление людьми? Управление компетенциями? Структура и процессы ИТ-производства? Регулярный менеджмент?
Да все это не нужно, ребята!

Пришел устроить небольшой научно-познавательный ликбез про Agile (Scrum) в формате диалога Заказчика и Исполнителя:

Заказчик: Хочу сделать проект
Исполнитель: Без проблем, давайте делать. Где ТЗ?
З: Вы так говорите, как и предыдущая команда. Мы на них сливали весь бюджет год, и потом еще год переделывали, чтобы этим можно было пользоваться
И: Понятно. Значит, давайте так: мы возьмем две недели, и за эти две недели сделаем первые пару экранов с функциями, чтобы ими можно было уже пользоваться.
З: А ТЗ?
И: ТЗ не надо, тут две недели-то всего.
З: А без ТЗ вы не сможете учесть все мои требования
И: Конечно, не сможем, мы ж не телепаты. Поэтому надо будет по первому же запросу давать нам доступ к экспертам, кому мы делаем эту систему - прям будущим пользователям. Это так важно, что мы назначим специального человека - Product Owner, который и будет отвечать за требования и приоритеты.
З: Но за две недели вы не успеете сделать руководства для пользователей
И: А и пофиг - главное, что ПО будет работать у реальных пользователей, а за две недели сильно сложный космолет не сделать.
З: И протестировать целиком не удастся
И: А и пофиг -- главное, что мы готовы в следующей забег взять самые злые баги, которые у вас найдутся
З: И как быстро вы сможете двигаться?
И: Да фиг знает. Но у нас самые мотивированные ребята, и мы все будем стараться непременно ускоряться. А если что-то (или кто-то) мешает, мы его устраним из процесса
З: И когда вы сможете закончить проект? Расчитать не удастся
И: Да и пофиг! Вам раньше приносили планы, и как -- вы в них уложились? То-то же

З: Хм. Работа рывками, нет долгосрочных планов, постоянный задел на переделки. Чем это отличается от обычного БАРДАКА?
И: ¯\_(ツ)_/¯ Зато это быстрый бардак, в котором все чем-то заняты!

Доступный ИТ-рынок катится в непонятное состояние. Проджект-менеджеры не умеют управлять содержанием проекта, продакт-менеджеры не умеют в постановку и execution задач, и оба не умеют управлять вверенными командами (даже на 3 человека)напрямую без тимлида.
Про последнее хочется сказать отдельно, ибо выглядит это как шантаж:
- 1 разработчик - слабая команда, не сделать что-то серьезное, нужен и бэк, и фронт (нанимаешь)
- 2 разработчика - слабая команда, не сделать что-то серьезное, скорости команды недостаточно (нанимаешь)
- 3 разработчика - слабая команда, нужен отдельный спец для тестирования (нанимаешь)
- 4 человека - слабая команда, задач много, теперь нужен еще отдельный аналитик (нанимаешь)
- 5 человек в команде: все, приехали, людей уже столько, что запрашивают еще тимлида в эту команду, который будет отвечать за исполнение задач, иначе руководитель "выгорает".

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

"Программирование МК-61 имеет глубокий философский подтекст.

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

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

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

Почему в России редко применяется известный принцип управления "кнут и пряник"? Не работает: пряник крошится при ударе

Кто о чем, а я о своем: дело "Седьмой студии" иллюстрирует, что если ты зав.студией (CEO), то ты в первую очередь менеджер, CFO и юрист с полной ответственностью за результат, а уже во вторую -- специалист по драматургии, вдохновитель и такое прочее. Аналогично -- к главрачам, техническим директорам, руководителям разработки и другим C-level.

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

В одном ИТ-чате проскочило интересное, хочу поделиться:

"ПМы - странные люди.  Всегда, какую обязанность не возьми, они за нее не отвечают.

C бизнес-заказчиком пообщаться — нет, пусть аналитик работает.
Про оплату счета напомнить — пусть аккаунт звонит.
Оценку сделать — пусть тимлид разработки распишет.
Задачи поставить — «я стратег, а не тактик»

Так и отказался я от ПМов вообще"