Блестящая кнопка

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

* * *

Прозрачный интерфейс андроид-приложения

Чувак, вдохновившийся блестящей кнопкой, сделал прозрачный интерфейс приложения, через который просвечивает окружение.

* * *

Как три корпорации монополизировали музыкальный рынок США

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

* * *

Последние три дня Silicon Valley Bank

Как накрылся краеугольный банк кремниевой долины.

* * *

История создания гитарной педали Big Muff

И причём тут вылавливание мячиков из канализации.

* * *

Чем зарубежные продакты отличаются от российских

И довольно сильно.

* * *

5 этапов собеседований в крупную айти-компанию

Готовимся и ведём себя правильно.

* * *

Про Старбакс

Почему это не кофейня, а необанк и другие особенности их бизнеса.

* * *

Быть тимлидом, ожидания и реальность

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

* * *

Доходность инвестиций в 2022

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

* * *

Чему учат путешествия

Почему успешные люди так любят путешествовать и что это даёт.

* * *

Лимит сообщений в Телеграм

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

* * *

Проблема 2000

Как это было, во что вылилось и кто на этом заработал

* * *

Приложение для транскрибации аудиозаписей

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

* * *

Ругаю сотрудников за переработки

Менеджеры проектов делятся своими подходами к работе.

* * *

Киберпанк по-русски

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

* * *

Бешеные псы против антифрода Яндекса

Разбираемся, можно ли скликать рекламу конкурента в Яндекс Директе

* * *

15 стратегий роста продукта

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

* * *

Билл Гейтс о нейросетях

По мнению основателя Майкрософта, появление AI сравнимо по значимости с изобретением графического интерфейса.

* * *

Нейросетейвой Last of us в советском антураже

С борщевиком.

* * *

Почему тик-ток не стал русским

Как был продолбан очередной стартап. Такое всегда интересно.

* * *

Обзор книги «The Halo Effect»

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

* * *

Хорошо, что вы это сказали

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

* * *

Как чувак пролюбил 6,7 млн. руб. на разных бизнесах

Историй успеха выше крыши, а вот про провалы редко кто рассказывает откровенно.

* * *

Upskayl

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

* * *

Зилант-2010. Хельга Эн-Кенти — .Ото-химэ

Снова будут складно врать, что случалось им встречать дочь властителя морей, Ото Химэ.

* * *

Поисковик по форумам

Форумы — всё ещё лучший способ получить развернутое мнение на любую тему.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У вас четыре варианта подхода к найму исполнителей. 

1. Инхаус-команда.
2. Один или несколько фрилансеров. 
3. Аутстаф команда под полным вашим контролем. 
4. Подрядчик, которому вы поручаете работу под ключ. 

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

Инхаус команда

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

Вариант хорош, когда приложение планируется очень сложным и дорабатывать его предполагается длительный период (в нынешних условиях «длительно» — это 2-3 года). По деньгам вариант получается чуть ли не самым дешёвым, дешевле только фрилансеры. 

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

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

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

Один или несколько фрилансеров

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

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

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

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

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

Аутстаф команда под вашим контроем

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

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

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

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

Подрядчик для работы под ключ

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

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

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

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

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

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

Гит

На проекте я тимлид,
В мастер пушу свой коммит, 
У меня на это есть
Полный доступ в гит.

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

Код ревью

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

CI/CD

Эту загадочную аббревиатуру нужно внедрять в третью очередь, когда гит и код ревью уже заработали. Даёт великое множество профитов — возможность гибко управлять правами доступа, автоматизировать ручные действия и самое главное, возможность нормально масштабироваться. Без CI/CD в случае резкого всплеска нагрузки вам останется только развести руками.

Прозрачный процесс постановки задач

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

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

Руководитель изрыгнул в чат баг или очередную светлую идею — ответственный сотрудник заводит тикет в таск-трекере и скидывает в чат номер. Исключений нет.

Одна задача = одна ветка в гите.

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

Автотесты

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

Мониторинг ошибок

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

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

Вот, в целом, и все полезные практики, которые вам нужно завести в свежем стартапе чем раньше, тем лучше.