В тот момент когда была фирма, частенько шутили с коллективом по поводу, того, что фирму можно посадить в большой трейлер и каждый день высаживаться работать в новом месте на природе или прикупить корабль и выходить в нейтральные воды, чтобы не нужно было платить налоги.
И вот сегодня задался сходным вопросом, сколько стоит небольшой остров…. и обнаружил, что остров в 30 акров (порядка 1 км квадратного) недалеко от Чили можно прикупить за $30K. Да…да… Я не опечатался, именно за 30 тысяч долларов (что примерно равно цене 2х комнатной квартиры в Харькове) и примерно равно 1/8 стоимость квартиры в штатах (в том месте где я нахожусь).
А может быть, махнуть на острова…. Поставить себе спутниковый инет и работать себе попивая пивко на берегу собственного острова.
Никто в складчину не хочет прикупить островок в средиземном море?
Очень у меня смешанное отношение к архитекторам (естественно софтверным).
С одной стороны, без них как-бы тяжко… Особенно, когда проект становится большим, все программисты погрязают в каких-то деталях своих частей проекта и нужен кто-нибудь, кто взглянет на это все сверху и скажет…. э… как у вас все запущенно, а давай-те выделим три системы, введем новый тип объектов и тогда наступит всем счастье.
Но, вот, что меня убивает на корню, когда архитектор простейшую операцию а-ля «почистить зубы» начинают обсмаковывать. А ведь можно почистить не только зубы, да и зубы можно не только почистить но и прополоскать. Итого, давайте введет объект действия и тип действия. Да, а ведь еще есть и цель действия. Тоже, для обобщения введем ее туда. И все эти действия объект может делать над субъектом. Итого, получаем эдак 3-4 разных сущности, которые посылают друг другу сообщения. Ну и само собой, все это может быть распределенным, если например дантист чистит чужую вставную челюсть, так что все это построим на базе SOA.
Почему космические архитекторы? Да потому, что если обычные архитекторы смотрят сверху вниз на код, с высоты многоэтажки, то эти настолько абстрагируются от всего, что уходят в какие-то занебесные космические области, по абстрагированию.
Повидал несколько компаний, который абсолютно по разному относятся к тому, нанимать внешние компании для выполнения каких-то работ или пытаться все делать внутренними силами.
Одна компания фактически сто процентов разработки, настройки и т.п. делала внутри. Точнее даже так, поработала с несколькими внешними компаниями, получила отрицательный опыт и теперь все делает сама.
Вторая компания, наоборот, выносит постоянно какие-то проекты, задачи, направления во внешние фирмы.
Естественно, за наем внешних компаний говорит то, что обычно нанимают компанию обладающую большим опытом в том, что она будет делать, плюс это экономит время сотрудников на какие-то более важные задачи и в случае если компания в оффшоре, то еще и деньги экономит.
А против, то что не всегда результат выходит желаемого качества, опыт не накапливается в компании и плюс дополнительные затраты.
Мои 2 цента по этому поводу. Как по мне, наймом со стороны пользоваться таки нужно, но делать это с умом.
Самое главное — это то, что никакая ключевая функция фирмы не должна выноситься из фирмы. Это правда очень стандартное и тривиальное замечание. Но капу чуть глубже, так как обычно проводят черту так — либо разработка ключевая (не выносим), либо не ключевая (выносим). Я бы проводил бы черту скорее по проектам/задачам. Например разработка следующей версии, которую ожидают самые ключевые заказчики — вещь ключевая и доверить это сторонней фирме как-то нехорошо. А вот например медленная и планомерная поддержка старых версий — вполне таки вещь, которая не так критична.
Второе замечание — это то, что нельзя выносить ту активность, которую никто не может проверить. Условно говоря, если нанять мощного архитектора со стороны, а в компании одни только средненькие программисты, то они никак не смогут проверить качество предоставляемой архитектуры. Безусловно, архитектора и будучи он сотрудником проверять будет некому, но вот если позже что-то пойдет не так и окажется что он явную фигню делал, то гораздо больше рычагов влияния на него (увольнение, не давание ему хороших отзывов).
Третье — это то, что выносить нужно только тогда, когда вынос приносит выигрыш по критическому ресурс. Обычно он приносит или уменьшение затрат или времени, редко оба пункта. И если для компании критично время, а она выносит для сокращения затрат — ни к чему хорошему это не приведет.
И четвертое — нельзя выносить то, что понадобиться завтра. Возвращаясь к тем самым багам в старой версии. В целом, знания связанные с исправлением этих ошибок будут дальше цениться все меньше и меньше. С другой стороны, если например компания собирается переходить с одной технологии на другую, то перенос проекта на новую технологию (даже если это не критичный сейчас проект), лучше таки делать внутри, так как ценность этих знаний как раз будет дальше возрастать.Что безусловно можно сделать, привлечь снаружи эксперта, который будет консультировать по особенностям технологии, но не более того.
Сегодня, у меня солянка сборная. На повестке дня три темы:
— организация совещаний
— соотношение менеджеров и исполнителей
— американский миф о команде
Итак по поводу совещаний. Я малехо удивлен, что фактически не в одной организации не проводятся нормально совещания, хотя в штатах, даже на простейших курсах, которые я проходит (Business communication для людей у которых английский — второй язык) рассказано как их разумно вести.
Частенько, особенно крупные и серьезные совещания, похожи на борьбу без правил — смешиваются в кучу кони, люди, все что-то пытаются сказать, мысль куда-то постоянно кочует, одно и тоже пережевывают по семь раз, общение разбивается на какие-то подгруппы. В целом твориться полная кутерьма.
А теперь быстренько по пунктам, что нужно для толкового совещания:
а) Длительность митинга должна быть обозначена заранее.
б) Вопросы, которые обсуждаются на митинге должны быть определенны заранее. А также нужно определить, желаемый тип результатов — решение, список идей, мнений или что-то другое.
Кстати, оба этих пункта озвучиваются и до митинга и повторяются в самом начале митинга.
в)Должен быть координатор совещания.
Это человек, который следит за тем, чтобы всем давали высказаться и не перебивали, возвращал обсуждения в запланированное русло и главное, если обсуждение вопроса затягивается, останавливал обсуждения и принимал решение о вынесение обсуждения деталей на отдельное совещание. Плюс, чаще всего, такой человек еще и ведет записки — сгенерированные идеи, принятые решения, возникшие дополнительные вопросы.
в) Должен быть человек, который имеет право принимать решения. Особенно, это важно если совещание собрано именно для принятия решений, а не для генерации идей. Я, вообще, очень сильно настаиваю на то, чтобы в компании было достаточно четкое разделение прав, ответственностей и полномочий. Так вот, должен быть человек, который может авторитарно сказать — мы идем путем A, а не путем Б.
г) В конце митинга, проходится еще раз по плану и по выписанным решениям, идеям и действиям, которые надо сделать после митинга.
Усе… Этого достаточно, чтобы совещания не были местом спячки и разгребания накопившейся непрочитанной почты, а местом где собираются, чтобы делать что-то полезное.
Слава богу, что в IT на территории exUSSR пока не сильно прижился этот американский стандарт.
Второе, что я хотел сказать — это соотношение менеджмента и исполнителей. Кстати, оказалось я об этом уже говорил тут. Хотя со мной и не согласились, но я считаю, что у чистого менеджера не должно быть больше чем 7 прямых подчиненных, но и меньше чем 4-5 тоже не должно быть. Как только вы обнаруживаете, что у вас 4 программиста, 3 тестировщика, 1 project manager и 2 product manager, 1 director, 1 CEO, 1 CFO, 1 CTO и т.п., то значит в королевстве датском, не все в порядка, так как общее соотношение по фирме выходит один исполнитель к одному менеджеру. Чаще всего этим болеют молодые компании, которым ну оооочень хочется, выглядеть большими и серьезными. Но, чаще всего, это проходит, как только становится видно что деньги утекают с какой-то сумасшедшей скоростью.
И третье — американский миф о команде. В нескольких книгах читал, да и в жизни видел, как здесь любят идею — собери хорошую команду, а хорошая команда тебе решит любые проблемы. Так вот… фигня это. Не совсем конечно фигня, но достаточно сильно. Ясно, что с хорошей командой легче решать все проблемы, чем с плохой. Однако, во первых команда — только часть всего, есть еще деньги, есть процессы, есть заказчики, есть идея, есть продукт или услуга построенные на этой идее, есть контакты, есть удача и т.п. И абсолютно не стоит надеяться, что одной хорошей командой удастся заткнуть все дыры.
