Pull to refresh

Comments 52

Парни из Badoo, откройте секрет: как нормальная, но прямо скажем, не выдающаяся статья получает за час 27 лайков и — сюрпрайз, сюрпрайз — ни одного комментария? ;)

Подозреваю, что лайкают мемасики, хотя в душе надеюсь, что все-таки статью (:

наш отдел серверной разработки за последние пару лет вырос вдвое (сейчас нас больше сорока человек)
А кто не лайкнет — останется без обеда!
В это время в корпоративном чате Badoo:
Почему за час всего 27 лайков!?
Зачем у нас 129 сотрудников на Хабре?!
UFO just landed and posted this here
Текучка у нас не планируется, ее сложно планировать:)
Один человек в месяц — это действительно не много, но сложность в объеме, который человек должен изучить. У нас это довольно много. Поэтому окупилось на первых же пришедших.
В целом очень близкие мне вопросы затронули, было интересно прочесть, спасибо. Разрешите два вопроса:
1. Обязательные встречи могут быть тяжёлым испытанием для интровертов. Что вы об этом думаете?
2. Три раза перечитала, но, извините, так и не поняла, чем Quick Start фундаментально отличается от набора базовых статей в wiki.
Спасибо!
1. Я сам интроверт, людей не очень-то люблю, поэтому мне тяжело, но я стараюсь изо всех сил! А если серьезно, то, это ведь коллеги, люди, с которыми человек будет или уже успел поработать, все свои. Он/она ведь смог пройти собеседование с незнакомыми людьми, а здесь уровень стресса ниже на порядок.
2. Всё так. Набор базовых статей, которые подаются в определенном порядке, в них собрана только важная информация достаточной “глубины”, которая с большой вероятностью понадобится во время работы, а так же снабженная практическими заданиями для закрепления. Wiki в нашем случае — просто инструмент.
Обязательные встречи могут быть тяжёлым испытанием для интровертов
Ну вот опять неверное понимание интровертов. Интроверты не против обязательных встреч, интроверты против необязательных встреч.
Обязательные встречи могут быть тяжёлым испытанием для интровертов.

Даже аутисты нормально общаются на профессиональные темы.
Обязательные встречи могут быть тяжёлым испытанием для интровертов.

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

Спасибо, было интересно прочитать.
Проблема может во многом решиться, если тестировщики/модераторы и прочие сотрудники будут отсылать грамотные тикеты, описывая проблему в нескольких предложениях. Либо же собрать свою систему тикетов с подключенным wiki. Банально подставлять под некоторые термины соответствующие статьи и определения на wiki. На разворачивание такой системы, имхо, ушло бы не больше времени, чем на написание тестов для закрепления Quick Start.
Спасибо!
Про грамотные тикеты не совсем понял: каждый постановщик (например, QA или продакт) должен знать о том, как внутри работает фича, и дать краткий овервью по ней?
Наверное, мы могли бы давать какие-то подсказки, но я вижу здесь две потенциальные проблемы:
1) “Я никогда не делал тикеты, в которых упоминались А, Б, Ц, поэтому я про эти инструменты ничего не знаю“
2) Где-то все-равно хочется рассказать человеку про наши процессы, про инструменты расследования проблем с перфомансом, тестирование, устройство инфраструктуры, и тд.
Возможно, Вы переоцениваете время на создание такого теста. На интерфейс ушло, может, пол дня-день. Вопросы собрали с миру по нитке. Профит!
каждый постановщик (например, QA или продакт) должен знать о том, как внутри работает фича, и дать краткий овервью по ней?

Не совсем. Я говорил о том, что из тикетов можно убрать сленговые речи, оставив только конкретику. К примеру, фразу «Пользователь %username% апнул свои рулы до модера без пэймента и тем самым попал в moderators_list» можно расписать как «Пользователь %username% смог поднять собственные привилегии до модератора без оплаты и попал в таблицу moderators_list». Так хоть и немного дольше расписывать, но и новичку будет многое понятно и без Quick Start.
Хотя полностью соглашусь с вами в том, что новичок должен освоить основные рабочие процессы, в особенности — собственной команды.
Про тест — признаю, погорячился =) Спасибо за ответ!
Хороший пример про грамотную постановку тикетов. Без этого тоже никуда. Это немного другая проблема и никакой QuickStart не поможет ее решить.
В айти есть 3 категории количества: ноль, один и много. Есть большая разница между знаниями и навыками. Знания можно прочитать, а навыки появляются только с практикой.

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

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

Quick Start обычно имеет единственный минималистичный сценарий прохождения и составляется с акцентом на практику, достаточную для дальнейшего самостоятельного погружения. Это отличает его от чисто описательных статей в wiki, а так же от Tutorial, где отдельные нюансы могут разбираться во всех подробностях.
Спасибо. Не ожидал, но статья действительно здравая. Похожие фишки сам использовал.
Я конечно дико извиняюсь, но только у меня глаза выпадают от «засинькать» и «консьюумеру»?
Да, мягкий знак лишний :)
Не только. Мне бы не хотелось работать с тикетами, сформулированными таким образом.
Заметил одну частую вещь при начале работы в новом проекте: мало внимания предметной области в документации, часто подразумевается что человек с ней знаком хотя бы как потребитель. В итоге инфраструктуру более-менее знаешь, но названия сущностей, таблиц и т. п. мало что говорят. И хорошо если нет пересечения с обычными ИТ-терминами типа user, role и permission.
хорошая документация, читаемый код который соответствует документации, разбитие на компоненты, ну и тикеты хорошо оформленные, если к этому стремиться то и новичёк в вики желательно иметь 1 страничку где ссылки на джиру, конфлуенс, где брать код и CI всё само устанавливается без хаков, если к этому стремиться то никакой поддержки со стороны тимлидера не понадобиться, вопросы должны возникать только на уровне бизнеслогики.
для джуниоров всё сложнее, тут проще иметь ментора который исходя из умений обучаемого подскажет где почитать об технических решениях и инструментах постепенно давая более сложные задания иметь кучу ссылок на всё подряд не нужно, потому что всё сразу и не нужно никогда
+ естествено поставленный процесс разработки, тесты, код, ревью…
Каких же знаний и умений ждёт от вас отдел и в частности я, руководитель? Как минимум таких
Я не веб разработчик и не очень представляю насколько это много, но от этого списка мне поплохело)))
Каких же знаний и умений ждёт от вас отдел и в частности я, руководитель? Как минимум таких:
Я не знаю, что означает больше половина слов из списка, что следует за этим.
Но, видя в одной куче требуемых знаний и умений термины «Emails», «Tests», «Pushes», «IserInfo» и «WTF», почему-то самих тимлидов хочется послать на какую-нибудь аттестацию.
Как минимум.

А Badoo у меня ассоциируется с email спамом, что какая-то девушка посмотрела мой профиль и хочет со мной познакомиться. Наверно эта неразделенная любовь останется навсегда…
Спасибо за комментарий! Когда я готовил доклад, я рассчитывал на то, что покажу этот слайд, никто ничего толком прочесть не успеет, вопросов не будет. Но раз он стал частью статьи, где у читателей появилась возможность его внимательно изучить, попробую пояснить.
У нас, как и в любой крупной компании, есть свои термины, инструменты, подходы.
Например, HLAN/RLAN/ULAN/MLAN/XLAN — это просто термины, которые можно объяснить в одном предложении. Но без знания о том, что это, человеку будет тяжело.
Например, AD, UserInfo, CPQ — это наши инструменты. Их уже в одном предложении не объяснишь, что-то нужно показать, дать примеры кода, предложить попробовать.
Что касается списка, который приводите Вы (Emails, Tests, Pushes) — это все о том, как мы отправляем пуши, письма и пишем/гоняем тесты. Я ставлю 100 рублей на то, что вы это делаете не так, как мы. Именно поэтому они есть в списке.
Кстати, WTF в нашем случае — это не устоявшее выражение, а инструмент, созданный моим коллегой Grezz, который мы используем при расследовании проблем: он собирает различные ивенты (выкладки патчей, альтеры, рестарт сервисов, запуск а/б тестов и тд и тп), которые потом накладываются на графики, и можно быстро найти причину изменений.
Я предполагал, что это ваши штуки.
Поэтому контрольный вопрос: с какого бодуна человек, впервые приходящий устраиваться в вашу контору, уже должен «знать и уметь» все ваши проприетарные «технологии» и инструменты?
У вас есть предбадуарий?
Да ни с какого:) Но я, как лид, хочу, чтобы человек как можно быстрее со всеми этими вещами познакомился, и начал эффективно их использовать, нанося пользу направо и налево. В статье/докладе как раз рассказываю о том, как мы это знакомство ускоряем.
Тимлид, да и вся компания хотят, чтобы пришедший человек уже всё это знал и сразу садился за реальную задачу. Но они реалисты, потому хоть и хотят, но не рассчитывают на это сразу, а ждут пока человек разберётся. Где-то это пускают на самотёк, а тут показан один из примеров решения проблемы.
Наверно я неправильно понял текст. Вы ждете, что весь этот набор технологий новичок в конечном итоге выучит, работая уже у вас, так?
Тогда непонятно, зачем весь этот список, который по факту для внутреннего использования, светить здесь, в общей статье.

А насчет WTF — неординарное решение называть инструмент устоявшимся выражением да еще с такой расшифровкой.
Да да, доклад/статья в том числе о том, как мы знакомим новичков с нашими инструментами. Список засвечен только для того, чтобы читатели могли оценить масштаб.
По поводу WTF: Вы смотрите на график, на котором падают запросы (или растут ошибки). «Что за хрень?» думаете Вы. Тут на помощь и приходит WTF!
Небольшая неопределенность в тексте.
Извините за резкость.
AD — Active directory
BFQ — планировщик в Linux один из многих
И т.д.
Мое мнение, что вы вначале сами создали себе проблемы, наплодив жаргонизмов.
А теперь пытаетесь успешно их решать.
Если у вас такие тикеты, то мне вас искренне жаль. Неумение грамотно сформулировать задачу — это довольно распространённая беда
Про грамотную формулировку задач — поддерживаю. И речь не только про постановку тикетов, но и про общение с коллегами в целом.
А что касается примеров тикетов, то я их специально подбирал и даже позволил себе слегка подредактировать:)
Все так! К Вам приходит новый девелопер, а его первая задача уже прошла ревью и ушла в тестирование! Вот это была бы жизнь!
На собеседовании дали?
UFO just landed and posted this here
Ура! Хоть что-то мы изобрели! :D
UFO just landed and posted this here
> Поздравляю — вы изобрели документацию :D

Я что-то не видел, чтобы в документации был интерактивный опросник с посыланием в её конкретное место в случае неправильного ответа :)
Фактически это уже комбинация с учебником. А это очень много работы — не в плане движка, он пишется такой за день-два, но в плане тщательного подбора вопросов и ответов, и правильного описания, что не так.
Именно в этом, jIMHO, самое интересное место в статье.
UFO just landed and posted this here

А после этого испытательного срока можно бесплатно получить премиум на сайте? Мне для друга...

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

Иметь актуальную внутреннюю документацию крайне непросто, особенно если продукт не продаётся и нет специального отдела документации.
Её надо поддерживать. Надо поддерживать экспериментальные технологии. Нужно поддерживать связность документации — через mind maps и через гиперссылки. Нужно вообще УМЕТЬ писать документацию (это не каждому дано).

С таким подходом может даже и выпустите какой нибуть стоящий продукт, а не сосальную сеть.
RRD — омг, вы все его еще юзаете?)

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

А про два стула спрашиваете на собеседовании или во время онбординга?
Мы спрашиваем про две таблицы. Про два стула, к сожалению, все уже давно ответы знают.
Sign up to leave a comment.