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

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

В чем будет разница их действий?

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

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

У Кастанеды есть классное решение в его рассказах про Дон Хуана. Безумный индеец, который стирал грани реальности, Кастанеда как-то решился спросить у него сколько ему лет. Так как слишком бодро он носился по лесу для старика. Тот ответил, что не знает, так как отказался от прошлого. Нет прошлого — нет и сожалений и ограничений. Появляется пространство для веры.

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

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

А в субботу буду выступать на конференции с темой «Из программиста в CEO за 45 минут», поделюсь опытом, как не перестать программировать и начать руководить. Рассчитываю, что докладом повышу популяцию тимлидов. Причем тимлидом по любви. Грустная картина, когда тимлидом делают старшего программиста и он вынужден тянуть эту лямку. Помимо того, что не каждому этому надо, я вижу большую проблему, что нас не учат руководить. В школе дают для этого возможности, но не всем ими пользуются. Я вот не пользовался и учился уже на ошибках. Было больно, дорого, но интересно.

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

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

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

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

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

Никогда не понимал, как люди пьют этот кипяток :)

Когда покупаешь за день билеты у 3-х разных авиаоператоров, то познаешь боль дарк-паттернов.

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

Я думал меня не проведешь, но на третьем билете уже ввел карту и понял, что билет ощутимо дороже.

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

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

Самое лучшее, что я сделал для приведения проектов в порядок — настроил планфикс. Причем дело не в самом планфиксе, подойдет любая nocode / lowcode система. А в том, что это развязало руки руководителям отделов.

Раньше как было: накодили самописа. Какие-то скрипты, своя ERP. Сначала писал сам, потом, посадил свободного программиста.

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

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

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

Тимлид разработки пошел дальше. И пишет свои решения, в связке с телеграм ботами. Как вы поняли самопис никуда не денется, но появилась мастер-система.

Чем меньше цикл от идеи до внедрения, тем больше у людей мотивации внедрять изменения.

Попробовал заставить ChatGPT писать код. Когда читал что нейросети умеют писать код — смеялся и предлагал лет через 20 это обсудить. Предлагаю посмотреть видео, код вполне работающий.

При этом многие сразу думают, что программисты будут не нужны в будущем, но это заблуждение. Произойдет эволюционная цепочка: раньше программисты писали все сами в своем vim, не имея возможности погуглить. А сейчас кажется странным взять на работу человека, который не умеет гуглить. Так как умение скомбинировать свой результат работы с ответами на stackoverflow.com — явно повышает perfomance разработчика.

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

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

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

Таким образом станет меньше рутиной и скучной работы и больше сложной интересной.

Отметили 8 лет Alto. Офигенный год получился, чем сложнее тем интереснее. Выросли в людях, деньгах и проектах. Хочу с вами на взрослую тему поговорить — ценности компании.

Наш PR / HR Даша откопала старый набор ценностей и сказала, что дальше так продолжать нельзя, и все то, что мы писали 3 года назад можно выкидывать.

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

На самом деле не нужны, вернее нужен не документ. Нужны показательные истории, которые покажут, как у нас принято поступать.

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

Рассказать, как собрать ценности?

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

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

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

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

— Что такое дофамин и как он работает
— Делайте продукты от которых зависимость
— Почему разработка таск-менеджера — плохая идея
— За счет чего вырос инстаграм на старте и как удерживает рост
— Почему к стульчику икеи у нас столько любви
— Почему тиндер не поможет вам пожениться
— Как заставить себя 2 часа работать на беговой дорожке

https://youtu.be/70hcbjyJZ-Q

На 2022 год мы в Alto ставили цель прокачать техническую экспертизу, пора подвести итоги:

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

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

Laravel
В начале года к нам присоединился Никита. Помимо его опыта 10 лет на фреймворках, он решил, что не может оставить ребят на 1С-Битрикс в покое. И провел обучение Laravel. Я уже писал пост про это и в комментариях все предрекали, что все разработчики захотят перейти на Laravel, но нет, разработчики вдохновились и стали взрослее писать на Битриксе. Подключают Slim и собирают API для мобильных приложений и фронта.

React
Отдельная проблема была начать продавать фронт на React на Битриксе. Клиенты привычно смотрели на стандартный подход. Хотя мы уже давно работали на аутстафе и внутренних проектах на React. Да и сам я, если что-то пишу, то сразу на реакте.

В итоге вложились хорошо в несколько пресейлов проектов и в конце года пришел отличный проект, где собрали MVP за 3 недели на 1С-Битрикс + React, прям перед новым годом. Все выдохнули с облегчением, так как оформление заказа не пришлось собрать на sale.order.ajax.

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

А еще мы выросли по выручке на 50%, и немного по людям.

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

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

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

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

Для этого мы готовим серию материала по ним, вы очень поможете, если расскажете:
1. Какие проблемы при составлении матриц?
2. Почему еще не завели ее? Что останавливает?
3. Пришлете свои матрицы, я в будущей статье поставлю ссылку на вас.

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

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

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

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

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

У нас в Alto появился островок корпоративной культуры. Я долго сопротивлялся, так как не хотел плодить сущности и все общение было в единственном чате, но наш PR настояла, чтобы сделать чат с флудом. И не писать в общий чат все не по теме.

Теперь у нас есть чат «Alto кринжовник🍇», где обсуждается всё от машин до кринжовых мемов.

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

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

Лавина люлей.

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

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

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

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

Формула простая — лучше немного неприятно сейчас, чем полный писец потом.

Как решать:
1. Со стороны менеджера сделать покерфейс и говорить открыто о проблемах. Да, люли обеспечены, но лишаем права на незнание. Когда говорим о проблеме, то озвучиваем реальное решение. «Будем больше стараться» — не решение.
2. Со стороны заказчика, оценивать не только результат, но и умение менеджера найти проблемы и их решить. Для этого самому нужно иметь опыт управления проектами и решения заковыристых ситуаций, иначе как оценить?

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

Рост разработчиков стал более автономен. Компетенции стали расти быстрее и меньше стало пробелов в командных навыках.

А раз компетенции становятся управляемыми, то и проекты получаются успешнее.

Мы этот опыт описали в виде гайда, всего в 6 шагах и выложили на хабр.

https://habr.com/ru/post/717430/

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

Выбор имени для стартапа и ChatGPT

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

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

Критерии такие:
1. Короткое
2. Зона .io — чтобы стартаперы, точно за своего приняли
3. Легко диктуется и читается на русском. Никаких «c, как доллар» в названии

Причем тут ChatGPT? Долго искал и не нашел сервис, который показывает все свободные домены в зоне .io

А ChatGPT + напильник позволили сделать скрипт, который:
1. Комбинирует все возможные 4-х буквенные русские слова
2. Переводить их в транслит. Это позволяет избежать сложных транслитераций
3. Проверяет все эти слова, свободны ли они в зоне .io

И это все без нормального знания nodejs.

Скрипт доступен по ссылке: https://github.com/altocodes/get_free_io_domain

По результатам за 30 минут собрал список из 20 доменов, которые слух не режут и универсальны. Если кому-то как раз нужно было подобрать домен в io, пишите в комментарии + отправлю в личку файл.

Домен по итогам зарегистрировал, какой и зачем — расскажу в следующих постах.

Матрица компетенций для QA-специалиста.

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

Публикую матрицу компетенций для специалистов по ручному тестированию. Это уже 4-ая версия. Добавили туда больше теории.

Сама структура матрицы ориентирована на требования в заявках от клиентов. Местами проскакивает наша специфика, связанная с разработкой на 1С-Битрикс. Но эти пару пунктов, вы сможете заменить на свои стэки.

Что делать с матрицей?
1. Там 2 раздела на Junior и Middle.
2. Она помогает помимо регулярной практики специалиста еще систематизировать знания по теории и инструментарию
3. Для обучения до Junior, с учетом того, что у кандидата были курсы + несколько месяцев практики уходит 80-120ч самостоятельного изучения. До миддла раза в полтора больше.
4. Добавляете колонку для каждого QA-специалиста и фиксируете через чек-боксы результат достижения.
5. Мы фиксируем объем на квартал, который специалист планирует сдать
6. Раз в неделю / две, есть выделенное время, когда специалист рассказывает теорию и подтверждает сделанную практику. Это позволяет всем видеть регулярный прогресс.

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

https://docs.google.com/spreadsheets/d/1bkgaHhdmR4pQojGP6k1NtSJRw03EcHNzVHeSmPQMdPQ/edit?usp=sharing