|
Когда мы начали эксперимент со свободным графиком, я была уверена, что весь лабс будет приходить к часу - двум. Удивительно, но вместо этого:- треть компании приходит к 7, и уходит в 16
- большая часть приходит к 9-10 и уходит в 18-19
- пара человек периодически приходят к часу-двум
Интересно, изменится ли это зимой :)
|
|
Мы с ![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1) d_zh выступали на Product Camp пару недель назад. d_zh рассказывал про создание новых рынков, а я рассказывала про длинные ползучие итерации при разработке Единый Клиент. Кроме нас, на сайте CUSTIS еще много интересных докладов. Из того, что я слушала на кэмпе, мне понравились Оля Павлова (хороший доклад) и Алексей Ильин (не близкая нам тема, но интересно).
|
|
Ищем кого-то, кто способен сделать дизайн и корпус для нашего робота.
Зарепостите и заретвитьте, плс :)
|
|
Даже и не знаю, будет ли понятно кому-то не из Лабса, но все равно не могу удержаться :)
|
| » Про хороший отпуск :) |
|---|
4 правила хорошего отпуска:- Не читать ЖЖ, МойКруг, twitter, outlook, google calendar, teamcity, jira, confluence, hg, svn, профессиональные и новостные блоги (как же сложно блин, не читать-то это все, закладки-то везде - в телефоне, в айпеде, в ноутбуке ...). Всякие "бизнесовые" книги тоже не читать. В facebook ржать над смешными картинками и слегка комментить, не вчитываясь.
- Читать и смотреть необычное.
- Выключить телефон. Совсем.
- Быть физически недоступной Заказчикам, детям, родственникам, друзьям, знакомым, курьерам - всем, кроме d_zh , от которого все равно не спрячешься. Для этого обычно необходимо свинтить в другой город или страну.
При соблюдении вышеперечисленного невероятно хорошо отдыхается.
9 дней свободы от привычного информационного потока - потрясающе заряжает.
Я даже забыла, что у меня работа есть :)
Mar. 26th, 2012 @ 01:01 am
|
| » HFLabs - спонсор ProductCampSPB 2012 |
|---|
В Новый Год в своем списке 101 желаний я написала, что нам, как компании, было бы интересно спонсировать те мероприятия, которые нам нравятся.
Кандидат нашелся быстро :)
В этом году мы спонсируем событие, которое нам очень понравилось в прошлом году - ProductCampSPB 2012.
Мы с d_zh на нем будем выступать с 15-минутными докладами: d_zh про создание новых рынков, я про процесс разработки нашего Единого Клиента.
Надеюсь, в этом году product camp будет лучше прежнего 
P.S. Кстати, я со своим ужасным английским попала в рекламу Business of Software, самой классной конференции для собственников небольших софтерных компаний и прочих колоритных личностей. Эту конференцию мы бы тоже с удовольствием проспонсировали, но она, к сожалению, не принимает спонсорство. С ними только едой и интересными докладами можно расплатиться :)
Mar. 11th, 2012 @ 07:02 pm
|
| » Continuous Integration: Improving Software Quality and Reducing Risk |
|---|
 Эту книгу я купила за ее довольно высокий рейтинг на амазоне. Можно рекомендовать ее как введение в Continuous Integration, но объем, честно говоря, можно было бы сделать и поменьше.
Вообще, мы недавно с коллегами обсуждали, что индустрия книгопечатания, судя по всему, поощряет авторов раздувать книги. Иначе никак нельзя объяснить появление 500-страничных книг там, где можно было обойтись 50.
Вернемся к сабжу. Несколько моментов, которые лично мне запомнились:
* строгое ограничение в 10 минут на интеграционный билд (правда, автор честно признается что это не он придумал, а Кент Бек). Вот да, сколько у нас внедрен continuous integration (CI), столько мы боремся за скорость билдов. Иногда причины длинных билдов могут быть довольно причудливые: например, недавно мои коллеги обнаружили, что причиной 15-минутных билдов были закоммиченные на hg 2 года назад (и потом удаленные!) огромные тестовые данные. Как только эти ревизии выкосили - скорость билдов поднялась на порядок. Happy end :)
* рекомендация полностью пересоздавать БД при развертывании очередного релиза.
Вот не согласна с оратором. Полное пересоздание не позволяет отловить баг, возникающих при процессе миграции с одной версии базы данных на другую (а именно так оно происходит обычно у Заказчика). Мы тестируем немного другим способом - создаем базу предыдущей версии и прогоняем по ней миграционный скрипт.
* развертывание "одной командой" на платформе Заказчика. Думаю, это действительно то, чем стоит заняться в ближайшее время, т.к. сейчас наша практика трехнедельных релизов Единого Клиента сопровождается большими затратами времени, которые уходят на составление инструкций по развертыванию, сопровождение развертывания и пр..
* continuous дизайн ревью посредством подключения чего-то вроде checkstyle в CI систему. Мне кажется, это могло бы быть полезно (и мы даже делали это в свое время в ФАКТОР, используя Sonar). Но когда до этого реально дойдут руки - не знаю.
Еще мне очень понравилось описание Ambient Orb (далее сокращенно Яйцо). Яйцо стоит на рабочем столе и яростно краснеет в случае, если, например, билд фейлится или идет больше 10 минут. Область применения Яиц не ограничивается Continuous Integration. Яйца отображают пробки, курсы акций и пр. Интересно, у кого-нибудь из моих френдов они внедрены?
Feb. 24th, 2012 @ 06:50 pm
|
| » Дискриминация на собеседованиях |
|---|
|
Привет всем, меня зовут Лена и я занимаюсь собеседованиями 20% своего рабочего времени.
У нас небольшая команда (20+ человек), и мы очень тщательно набираем новых людей в нее (во всяком случае, стараемся это делать). Кроме широко освещенных в интернетах издевательств путем писания кода, особенностью наших собеседований является то, что мы отказываем совершенно нормальным людям, которых с руками бы отхватили в любой другой компании.
Примеры дискриминации, которые в hflabs являются нормой:
* не брать людей, которые опаздывают на собеседование более, чем на 15 минут или не могут сами дойти до офиса.
* не брать людей, которые приходят к нам только из-за денег (черт его знает как, но это чувствуется).
* не брать офигенно крутых технарей, у которых, по мнению команды, "не горят глаза".
* не брать тех, кто не нравится хотя бы одному члену команды собеседующих.
Все дело в том, что мы сделали слишком много кадровых ошибок, набирая таких людей первые 5 лет существования компании. Иногда мне кажется, что уже мы совершили все типы кадровых ошибок (но практика все время показывает: нет, еще не все... :).
Вот некоторые типичные грабли из тех, на которые лично я налетала:
* набрать неквалифицированного человека с надеждой вырастить из него квалифицированного (щас...);
* набрать сотрудника лет 30, который стремится к обучению и у него все как-то это не получается на текущих местах работы - то времени нет, то еще что-то (была надежда, что мы будем как раз теми, кто их наконец-то обучит и выведет в люди...);
* набрать коллегу, которому не нравилось начальство на предыдущих пяти местах работы, и убедиться, что с тобой ему хуже, чем со всеми ними, вместе взятыми;
* набрать коллегу, которому нравятся четко регламентированные обязанности и потом пытаться бесконечно согласовать с ним его должностную инструкцию;
* набрать коллегу, которому нравится спокойный темп работы и убедиться, что ему с тобой просто неуютно.
... (там еще много всего, я долго могу перечислять :)
Зато, как мне кажется, в результате этих шишек мы гораздо лучше начали понимать, кто нам нужен. Во всяком случае, текущий рейт приемов/увольнений гораздо ниже, чем был в предыдущие годы.
P.S. Сейчас я думаю, что умение отбирать правильных людей - чуть ли не единственное ценное качество хорошего руководителя. Если он не умеет этого делать - нужно выгонять его и набирать секретаря.
P.P.S. Если что, себя бы я выгнала уже раз 10.
Feb. 17th, 2012 @ 05:52 pm
|
| » Темная сторона agile манифеста: 7 лет спустя |
|---|
В B2B Заказчик привередливый. И у каждого Заказчика своя уникальная инфраструктура. Да что далеко ходить, даже если взять клиентские карточки: у каждого Заказчика свой набор полей и разные правила их обработки.
Поэтому так сложилось, что оба наших продукта (ФАКТОР и Единый Клиент) содержат логику, общую для всех Заказчиков, и набор специфичных настроек для каждого из них.
Преимуществом такого подхода, безусловно, является гибкость и возможность решать задачи конкретного заказчика вместо сферического коня в вакууме. А, соответственно, и высокая степень удовлетворенности заказчика, часто ведущая к высокой прибыльности проектов.
Недостаток гибкости в том, что она со временем доходит до неадеквата (достаточно посмотреть конфиги ФАКТОР за 7 лет) и становится трудноподдерживаемой и путаной. В этом месте передаю привет agile manifesto, ставящему работающий продукт превыше исчерпывающей документации. Из-за этого через много-много лет поддержки очень тяжело объяснить, что откуда взялось (оффтоп: кстати, никогда не понимала, что они имеют в виду, когда говорят о том, что слева круче? :).
Кроме того, вышеописанная архитектура приводит к необходимости поддерживать целый пласт инфраструктуры, связанный с Заказчиками, который отсутствует в традиционной продуктовой разработке:
* отдельные ветки в версионном контроле с конфигами заказчика.
* билды под заказчика в teamcity со специфичными наборами тестов.
* проекты в jira (для каждого заказчика свой проект с релизами специфичных именно для него фич).
* spaces в конфлюенс (с инфой по инфраструктуре заказчика, его требованиям, тестам и пр).
При этом, когда выпускается очередной релиз, тестируется и поставляется столько билдов, сколько у нас заказчиков (сейчас подсчитала в teamcity - это 40 с лишним билдов).
Понятно, что при таком подходе более чем оправдана высокая степень автоматизации тестирования, на которую тем не менее, часто не удается отвлечь команду, потому что нужно делать новые фичи, которые нужны для того, чтобы заказчик был заинтересован ставить новые релизы, чтобы нам не поддерживать кучу одновременных релизов. Бобер, выдыхай :)
P.S. Интересно, есть ли у нас на рынке компании с аналогичными процессами и проблемами.
P.P.S. Компании, делающие акцент на ручной ретест каждого поставляемого релиза не очень интересны.
Feb. 10th, 2012 @ 07:15 pm
|
|
|
|
