Khariton Matveev
Спасибо ) Мы правда старались!
Всё так :-) Skyeng — это не про дорогущий ремонт и фешенебельную мебель, а про умную эргономику, функциональность, традиции и заботу. Фишки нашего офиса в смысле, а не форме.
Мы старались )
Зато есть спортзал :-) Для тех, кто хочет заминусовать свой жирок..
Продолжайте, не останавливайтесь! Пополним беклог идей для HR :-)
Жень, меня зовут Харитон, я со-основатель и директор по продукту в Skyeng. Не смог быстро найти ваш Facebook или телефон — напишите мне на https://facebook.com/hmatveev, было бы интересно отбсудить ваше приложение.
Так как же нет? Про лог времени писал несколько раз в комментах — это обязательно используем. У нас нет систем как с операторами, когда мы с 9 до 16 контрлируем каждый их шаг.
Для учета времени, что мы тратим используем плагин Tempo для JIRA.
Увы, величину зарплат наших разработчиков не разглашаем :-)
А как вводятся новые разработчики? Новый разработчик получает доступы, знакомится с командой и начинает читать документы с конвенциями и архитектурой проекта. После этого ему дают простые небольшие задачи, потом сложность и ответственность увеличивается.
Раз время работы не контролируется - ставятся сроки на задачи?Мы не контроллируем, утром или вечером ты работаешь. Но мы контроллируем, что в неделю человек отработал +- 40 часов, а так же какие задачи он закрыл — и соотносим сложность задачи и итоговый код (который прикрепляется к тикету в JIRA автоматически) с сложностью задачи.
Как оценивается срок на реализацию?Стоимость оценивает разработчик, эпрувит тимлид. Если не согласны, они обсуждают и договариваются о разумной оценке.
Что если постановщик ошибся с оценкой и разработчик не по своей вине превысил срок?Ничего страшного — ошибся ведь из-за чего-то, что что-то не учёл. Теперь он стал мудрнее и знает о новой веще и в будущем сможет лучше сделать оценку )
Самый большой отклик на moikrug, иногда приходят интересные ребята с hh. Был положительный опыт использования сервиса AmazingHiring :-). А так же пиарим — распространяем в Facebook и часто наши вакансии берут на VC.
Возможно, есть идеи? :-) Если со стороны видно, какие у нас есть сильные стороны о которых мало писали — с удовольствием расскажем!
Зарплаты разные, так как у людей реально разный уровень. Так же ведущие разработчики (как и сотрудники) через год работы могут получить опцион, у нас здесь хорошая политика, сразу договорились с акционерами и зарезервировали под это определённую долю в компании.
Однако мы уже давно поняли, что дорогой опытный разработчик может делать в разы больше пользы (особенно в работе над сложными проектами, где всё плохо параллелиться), чем 2 или 3 разработчика ниже уровнем — сейчас в команде оставили только профессионалов.
Мотивации и KPI есть только перед руководителем разработки, для самих разработчиков пока ничего такого не делали, однако для ребят мы транслируем важные сроки — и это часто мотивирует, команда сплочаетс в энтузиазме заделиверить продкт в определенные рамки по времени или бюджету.
Что касается времени пресутствия, у нас есть 4 часа в день (с 12 до 17 с обеденным перерывом), когда мы ожидаем что все на месте — в остальное время каждый решает сам, когда ему удобнее работать. Это особенно актуально, так как есть ребята из совсем разных часовых поясов.
Спасибо большое! Тут коллеги писали и просили подробнее рассказать как мы используем Slack, с какими-то деталями и хитростями внутренней кухни — думаю, это из этого может получиться что-то интересное и полезное :-)
Да, как правильно ответил Саша — после испытательного срока мы подписываем договор и NDA с головной компанией по британскому праву.
По аудированию сейчас делаем аудиокниги — которые будут доступны всем нашим ученикам бесплатно между занятий и можно будет слушать и потом еще и проходить тесты на усвоение деталей текста.
По говорению — здесь в домашние задания сейчас специальный тип упражнения вставляем, когда ученику предлагается список вопросов и новая лексика и он должен начитать дома небольшой рассказ, который потом оценивает специальный методист.
Про code review и небольшие ежедневные летучки на 5-7 минут полностью согласен.
А вот подход «Нет отчета по итогам дня - рабочий день не учитывается при расчете зп.» всё же тут не работает. Ребята молодцы и хорошие, стараюсь просто разобраться почему не заполнили worklogs, может человек просто увлёкся задачей и забыл.
Вообще про логирование времени по задачам очень важно объяснить что это не инструмент контроля, а рассказать как это помогает компании — нам, например, очень важно знать сколько мы денег потратили на тот или иной проект (и JIRA умеет автоматически такие отчёты строить).
Понимаю вас, я сам в начале то же самое говорил нашему директору ) Что разработка может быть только в одной комнате.
Однако мы попробовали — и не пожалели. Конечно, правильно её построить и организовать сложнее, и людей нужно подбирать к этому предрасположенных и процессы грамотно ставить и мотивационные инструменты в оффлайн плохо переносятся. Однако же мне кажется, наш опыт говорит о том, что у нас не плохо это получилось.
Договорились :-)
По поводу грамматики — обязательно будем делать, причём что-то уже появится до конца этого года. А так же по приложению Words реализовали далеко не всё из задуманного!
Если мы делаем новую большую функциональность (которую разрабатывать, скажем, два месяца) и поделить никак не получается и выкинуть нечего — MVP в чистом виде, в этом случае делаем по waterfall, просто деля на небольшие задачки.
Если же есть MVP, то дальше запускаем agile, начиная процесс непрерывных улучшений.
Беклог задач конечно есть, с трудом представляю как можно без него обходиться :-) Основные трудности — поддерживать его в хорошем состоянии, когда нет дублей, задачи не теряются, они хорошо описаны и с качественными названиями, по которым можно понять, о чем идёт речь.
Самые передовые IT-команды движутся к моделям управления, которые сильно «уплощены», то есть нет понятия руководитель-подчиненный. Все работают над общей задачей с единой системой ценностей. И мы тоже стараемся двигаться в этом направлении.
Спасибо, Вань! :-)
Согласен с Вами, у кого-то удалённая работа понижает продуктивность (ведь не видишь коллег, легко отвлечься), возможно даже таких людей большинство. Однако у многих производительность выше (можно сосредоточиться, быть в тишине, не бегает менеджер за спиной и не отвлекает в оффлайне по своим вопросам). Это инструмент — и нужно научиться им пользоваться, правильно выбирать людей на собеседовании. Основная моя мысль в этой статье — что удалённая продуктовая разработка, это совершенно реально и мне кажется, люди неоправданно этого опасаются.
Мне очень жаль, если вы работаете в компании, куда вы приходите на работу ради денег. Мы делаем очень крутые продукты, меняем рынок образования и радуемся нашим общим успехам. Ребята из команды разработки всегда супер рады интересным публикациям о нас, когда СМИ публично хвалят продукт, или именитые клиенты оставляют классные отзывы )
Спасибо большое за добрые слова :-) Мы планируем запустить к концу года групповые занятия в мини-группах (до 3-4 человек) — хочется сделать их намного эффективнее обычных оффлайн-групп, поэтому разработка нового продукта занимает очень много времени. Но мы надеемся, что уже скоро сможем предложить продукт, доступный большей аудитории!
Про это могу написать отдельную статью. За что я больше всего люблю — это бесконечные интеграции (по сути, всё изо всех систем стекается в Slack, от фидбека пользователей до Alert систем мониторинга серверов). Ну и второе — крутейшие нотификации, я могу настроить для мобильного приложения, например, чтобы ко мне приходили 2 канала все сообщения, а вот с этих трёх — только те сообщения, где меня упомянули.
Большое спасибо, мы стараемся :-)
У нас работает отлично. Разрешите дать некоторые советы по тем проблемам, о которых вы написали:
Невозможно контролировать результат и процессРезультат конкретной фичи — пул реквест, другой разработчик или CTO смотрит код и его качество, менеджер открывает ветку с кодом на тестовой машине и смотрит, доволен ли он новой функцией.
Не ясны срокиВсе задачи разрезаются на кусочки, к каждой делаем хорошее описание, после чего команда на еженедельном митинге оценивает их, и мы формируем спринт. По большой функциональности меньшее понимание деталей, поэтому там дисперсия в сроках выше — но чем долгосрочнее планирование, тем больше нужно закладывать времени на то, что мы не донца понимаем предстоящий пулл работ.
программисты обычно "тянут" до цонца, в итоге ничего вовремя не сделаноНу это говорит о плохом менеджементе, как мне кажется. Мы режем крупные задачи на подзадачи, оцениваем их, менеджер в реальном времени на дашборде в JIRA видит, какие задачи сделаны, а какие нет, разработчик логируя время актуализирует Remaining time (сколько осталось времени до конца) — таким образом менеджер всегда в курсе, на сколько сделана задача, увеличились ли сроки и если да, то почему.
TeachBase
Ну у нас нет ничего, вроде X Box или игровых автоматов, то есть того, что могло бы отвлекать. Напротив, всё что мы делаем — продумываем, как это поможет продуктивности, улучшит коммуникации и будет транслировать культуру нашей компании.