Comments 52
Подозреваю, что лайкают мемасики, хотя в душе надеюсь, что все-таки статью (:
наш отдел серверной разработки за последние пару лет вырос вдвое (сейчас нас больше сорока человек)
Почему за час всего 27 лайков!?
Зачем у нас 129 сотрудников на Хабре?!
1. Обязательные встречи могут быть тяжёлым испытанием для интровертов. Что вы об этом думаете?
2. Три раза перечитала, но, извините, так и не поняла, чем Quick Start фундаментально отличается от набора базовых статей в wiki.
1. Я сам интроверт, людей не очень-то люблю, поэтому мне тяжело, но я стараюсь изо всех сил! А если серьезно, то, это ведь коллеги, люди, с которыми человек будет или уже успел поработать, все свои. Он/она ведь смог пройти собеседование с незнакомыми людьми, а здесь уровень стресса ниже на порядок.
2. Всё так. Набор базовых статей, которые подаются в определенном порядке, в них собрана только важная информация достаточной “глубины”, которая с большой вероятностью понадобится во время работы, а так же снабженная практическими заданиями для закрепления. Wiki в нашем случае — просто инструмент.
Обязательные встречи могут быть тяжёлым испытанием для интровертовНу вот опять неверное понимание интровертов. Интроверты не против обязательных встреч, интроверты против необязательных встреч.
Обязательные встречи могут быть тяжёлым испытанием для интровертов.
Даже аутисты нормально общаются на профессиональные темы.
Обязательные встречи могут быть тяжёлым испытанием для интровертов.
Если это обязательные тимбилдинги, во встречах нескольких человек обсудить проект/таски ничего такого испытывающего нет.
Проблема может во многом решиться, если тестировщики/модераторы и прочие сотрудники будут отсылать грамотные тикеты, описывая проблему в нескольких предложениях. Либо же собрать свою систему тикетов с подключенным wiki. Банально подставлять под некоторые термины соответствующие статьи и определения на wiki. На разворачивание такой системы, имхо, ушло бы не больше времени, чем на написание тестов для закрепления Quick Start.
Про грамотные тикеты не совсем понял: каждый постановщик (например, QA или продакт) должен знать о том, как внутри работает фича, и дать краткий овервью по ней?
Наверное, мы могли бы давать какие-то подсказки, но я вижу здесь две потенциальные проблемы:
1) “Я никогда не делал тикеты, в которых упоминались А, Б, Ц, поэтому я про эти инструменты ничего не знаю“
2) Где-то все-равно хочется рассказать человеку про наши процессы, про инструменты расследования проблем с перфомансом, тестирование, устройство инфраструктуры, и тд.
Возможно, Вы переоцениваете время на создание такого теста. На интерфейс ушло, может, пол дня-день. Вопросы собрали с миру по нитке. Профит!
каждый постановщик (например, QA или продакт) должен знать о том, как внутри работает фича, и дать краткий овервью по ней?
Не совсем. Я говорил о том, что из тикетов можно убрать сленговые речи, оставив только конкретику. К примеру, фразу «Пользователь %username% апнул свои рулы до модера без пэймента и тем самым попал в moderators_list» можно расписать как «Пользователь %username% смог поднять собственные привилегии до модератора без оплаты и попал в таблицу moderators_list». Так хоть и немного дольше расписывать, но и новичку будет многое понятно и без Quick Start.
Хотя полностью соглашусь с вами в том, что новичок должен освоить основные рабочие процессы, в особенности — собственной команды.
Про тест — признаю, погорячился =) Спасибо за ответ!
Обычные статьи в wiki имеют тенденцию превращаться в маленькую советскую энциклопедию, затягивая читателя надолго в лабиринте ссылок. Или большую, в зависимости от склонностей к литературному творчеству в компании.
Когда в голове нет совсем ни чего, то нет и вреда. Больше всего вопросов и ошибок возникает при первой встрече с технологией на практике. Поэтому лучше если все это непотребство происходит где-то в отдельном загончике, без связки с продакшеном. Необходимо, чтобы у адепта перед глазами есть простой пример, подсказывающий правильное решение.
Quick Start обычно имеет единственный минималистичный сценарий прохождения и составляется с акцентом на практику, достаточную для дальнейшего самостоятельного погружения. Это отличает его от чисто описательных статей в wiki, а так же от Tutorial, где отдельные нюансы могут разбираться во всех подробностях.
для джуниоров всё сложнее, тут проще иметь ментора который исходя из умений обучаемого подскажет где почитать об технических решениях и инструментах постепенно давая более сложные задания иметь кучу ссылок на всё подряд не нужно, потому что всё сразу и не нужно никогда
+ естествено поставленный процесс разработки, тесты, код, ревью…
Каких же знаний и умений ждёт от вас отдел и в частности я, руководитель? Как минимум такихЯ не веб разработчик и не очень представляю насколько это много, но от этого списка мне поплохело)))
Каких же знаний и умений ждёт от вас отдел и в частности я, руководитель? Как минимум таких:Я не знаю, что означает больше половина слов из списка, что следует за этим.
Но, видя в одной куче требуемых знаний и умений термины «Emails», «Tests», «Pushes», «IserInfo» и «WTF», почему-то самих тимлидов хочется послать на какую-нибудь аттестацию.
Как минимум.
А Badoo у меня ассоциируется с email спамом, что какая-то девушка посмотрела мой профиль и хочет со мной познакомиться. Наверно эта неразделенная любовь останется навсегда…
У нас, как и в любой крупной компании, есть свои термины, инструменты, подходы.
Например, HLAN/RLAN/ULAN/MLAN/XLAN — это просто термины, которые можно объяснить в одном предложении. Но без знания о том, что это, человеку будет тяжело.
Например, AD, UserInfo, CPQ — это наши инструменты. Их уже в одном предложении не объяснишь, что-то нужно показать, дать примеры кода, предложить попробовать.
Что касается списка, который приводите Вы (Emails, Tests, Pushes) — это все о том, как мы отправляем пуши, письма и пишем/гоняем тесты. Я ставлю 100 рублей на то, что вы это делаете не так, как мы. Именно поэтому они есть в списке.
Кстати, WTF в нашем случае — это не устоявшее выражение, а инструмент, созданный моим коллегой Grezz, который мы используем при расследовании проблем: он собирает различные ивенты (выкладки патчей, альтеры, рестарт сервисов, запуск а/б тестов и тд и тп), которые потом накладываются на графики, и можно быстро найти причину изменений.
Поэтому контрольный вопрос: с какого бодуна человек, впервые приходящий устраиваться в вашу контору, уже должен «знать и уметь» все ваши проприетарные «технологии» и инструменты?
У вас есть предбадуарий?
Тогда непонятно, зачем весь этот список, который по факту для внутреннего использования, светить здесь, в общей статье.
А насчет WTF — неординарное решение называть инструмент устоявшимся выражением да еще с такой расшифровкой.
По поводу WTF: Вы смотрите на график, на котором падают запросы (или растут ошибки). «Что за хрень?» думаете Вы. Тут на помощь и приходит WTF!
BFQ — планировщик в Linux один из многих
И т.д.
Мое мнение, что вы вначале сами создали себе проблемы, наплодив жаргонизмов.
А теперь пытаетесь успешно их решать.
— вчера!
Я что-то не видел, чтобы в документации был интерактивный опросник с посыланием в её конкретное место в случае неправильного ответа :)
Фактически это уже комбинация с учебником. А это очень много работы — не в плане движка, он пишется такой за день-два, но в плане тщательного подбора вопросов и ответов, и правильного описания, что не так.
Именно в этом, jIMHO, самое интересное место в статье.
А после этого испытательного срока можно бесплатно получить премиум на сайте? Мне для друга...
А если серьёзно, то всё приходит со временем — достаточно иметь актуальную внутреннюю документацию, а с остальным новый сотрудник разберётся на практике.
Иметь актуальную внутреннюю документацию крайне непросто, особенно если продукт не продаётся и нет специального отдела документации.
Её надо поддерживать. Надо поддерживать экспериментальные технологии. Нужно поддерживать связность документации — через mind maps и через гиперссылки. Нужно вообще УМЕТЬ писать документацию (это не каждому дано).
Добро пожаловать на борт: вводим новых разработчиков в команду