Subversion всегда был удобен такими фичами как, атомарные commits, версионированные директорий, хорошая поддержка бинарных файлов, быстрое создание бранчей и тагов, поддержка нескольких сетевых протоколов, в том числе и HTTP. Но, чего действительно раньше не хватало в subversion, так это возможности найти какой код был смержен, откуда он мержился и когда это произошло. Отсутствие такой возможности приводило раньше к трудностям при мерже:

К примеру, пользователь не сможет смержить изменения с 11 по 17 ревизию в бранч, если он уже мержил 11 и 13 ревизии в бранч ранее. В новом subversion мержи логируются и нет больше необходимости записывать на листик, какой код, когда и откуда мержился.

Разработчики subversion как будто услышали мои мольбы и добавли change lists –функционал, позволяющий ассоциировать произвольные файлы с неким человекочитаемым именем. К примеру вы работаете над несколькими багами одновременно, и по окончании одного из них хотите залить его в репозиторий. А файлы, относящиеся к другому фиксу – оставить в локальном репозитории. Раньше приходилось прибегать к помощи листика, чтобы разделить эти два набора файлов и залить только нужные файлы. Теперь проассоциировав первый набор файлов с неким именем, вы можете по окончанию работ просто указать имя этой группы файлов и они немедленно попадут в основной репозиторий.

Еще одна полезность, появившаяся в 1.5 subversion – это sparse checkouts, позволяющий выполнять основные операции только над указанными уровнями дерева каталогов. Это удобно, если вы не хотите “слить” только текущий каталог со всеми файлами в нем, но не хотите “сливать” все его поддиректории. 

Также было добавлено интерактивное разрешение конфликтов – теперь svn сам предлагает варианты решения конфликта. Лично для меня эта фича никакой погоды не делает, так как я давно пользуюсь Araxis Merge, чего и вам советую.

Не знаю почему, но большинство GIT’овцев кричат: SVN sucks, попробуйте GIT – у нас проект в жите 2.5 гига и ничего не тормозит. У меня, я вам скажу, есть проект около 4 гигабайтов в архиве. То есть сжатый RAR’ом. И я никаких тормозов не наблюдал еще с версии 1.4.6. А в версии 1.5 ускорена работа из-за простого трюка – они сделали более многовложенную файловую систему, т.е. в одной директории такого дикого количества файлов уже не будет. И это важно, особенно, если ваш сервер хранит репозиторий на Network Attach Storage с не самой продвинутой файловой системой, которая тормозит при 10 000 файлов. Из-за того что в subversion файлы readonly, это позволяет улучшить стратегию кэширования на стороне NAS’ов и других умных файловых систем. Теперь неизменяемые файлы сгруппированны в каталоги, и вашей файловой системе можно сказать: вот эти каталоги неизменяемы (после появления файлов в ней) и ты пожалуйста это учти.

Разработчики клянуться, что теперь заработает CTRL+C!

Появилась возможность задавать относительные пути, которые могут быть полезны, если вы не хотите плодить какие-то сторонние библиотеки в нескольких проектах, но хотите иметь их локально.

Как мы видим, управлять репозиторием теперь станет легче, работать он будет быстрее, а разработчики перестанут записывать на листике, что и когда они мережили ;)

Ссылки по теме

Subversion 1.5 Release Notes

Subversion: чеклист по правильным коммитам

Слияние: Руководство по ежедневному использованию

Merging and branching in Subversion 1.5

Subversion or CVS, Bazaar or Mercurial?

Get that job at Google - очень интересная статья с советами по поводу того, как проходить собеседование в Гугле. И она не зря такая популярная, она действительно очень хорошо и вдумчиво написана. Там рассматривается процесс собеседования в принципе, и даются советы, которые подойдут для прохождения собеседования в любых программерских компаниях.

Компании наподобие Гугла ставят высокий барьер, при отборе кандидатов. Лучше отказать квалифицированному кандидату, чем взять на работу неквалифицированного.

Спорный вопрос, но думаю, Гуглу виднее.

Не стоит переживать, если вас не взяли на работу. Причинами для этого могут быть:

1. у вас был просто неудачный день
2. у вашего интервьювера был просто неудачный день
3. вы просто не поняли друг друга (вас и интервьювера) на собеседовании
4. вам не повезло и вы попали на Interview Anti-Loop

Полностью согласен с автором. Не стоит волноваться и во время собеседования – это может понизить ваши шансы на успех.

Каждый опытный интервьювер имеет набор излюбленных тем и вопросов, которые, по его мнению, позволяют раскрыть талант кандидата. 

Да, и это проблема от которой нужно избавляться – собеседование должно быть гибким настолько, насколько это возможным.

На собеседование необходимо всегда приходить подготовленным.

Даже если вы лучший программист в своей компании, если вы уже долгое время успешно пишите крупный и сложный проект, это вовсе не значит, что вы сможете ответить на все вопросы интервьювера. Ведь удержать в голове знания всех алгоритмов, технологий и подходов с которыми вы сталкивались невозможно. А если на каждый второй вопрос вы будете отвечать: “Да я сталкивался с этим, но это было очень давно и сейчас я не могу ответить на ваш вопрос.”, – то у интервьювера сложится впечатление, что вы самоуверенный, высокомерный и ничего не умеющий джуниор. Поэтому необходимо освежить память перед собеседованием.

Шаг 1 – Изучить теорию алгоритмов и структур данных . Зачем? Потому что это поможет вам распознать проблему, которую вам предлагают решить на собеседовании. Большинство интервьюверов любят, когда их вопрос понимают без дополнительных пояснений. К примеру, если вас попросили разукрасить флаг Штатов, то вашим большим плюсом, будет увидеть в этом вопросе проблему раскрашивания графа. А если вы еще вспомните и решение данной проблемы, то ваши шансы пройти собеседование резко повысятся.

Основные вещи, которые должен знать и понимать любой программист: оценка сложности алгоритмов, различные алгоритмы сортировки, хэш-таблицы, деревья, графы (поиск в ширину, поиск в глубину), NP-полные задачи. Вам необязательно реализовывать все это в повседневной работе (реализация этих вещей уже есть в большинстве фреймворков), но понимать как это работает просто необходимо.

Автор рекомендует две книги для подготовки в области теории алгоритмов и структур данных: The Algorithm Design Manual Стивена Скинса и Introduction to Algorithms Томаса Кормена. От себя порекомендую Алгоритмические трюки для программистов Генри Уоренна и Алгоритмы: построение и анализ того же Т. Кормана. В свое время эти книги помогли мне занимать призовые места на национальных соревнованих по программированию.

Шаг 2 – Попросите товарища прособеседовать вас. Друг должен задавать вопросы из различных областей. И вы должны отвечать на них, не важно насколько вы устали или просто ленитесь на них отвечать.

Это не только поможет вам освежить память в тех областях, с которыми вы работали давно, но и позволит вам научиться формировать точный и ясный ответ. Мне часто приходится видеть на собеседованиях, что человек понимает о чем идет речь и даже знает ответ на мой вопрос, но он попросту не может внятно сформировать свой ответ. Возможно это издержки технической профессии – недостаток повседневного общения.

Не ведите себя высокомерно на собеседовании. Лучший способ показать свое высокомерие – поставить под сомнение профессионализм собеседника, поэтому никогда не спрашивайте: “Вы действительно считаете, что все эти алгоритмы важны? Вы полагаете их стоит использовать в реальной жизни? Никогда не слышал о подобном подходе…”. Лучше просто признаться, что вы не знаете или не помните ответ на этот вопрос. Также, не бойтесь попросить подсказку или помощь при ответе на вопрос – некоторые интервьюверы любят, когда их талант признают и просят у них помощи.

Не старайтесь сменить тему и ответить на другой вопрос. Не пытайтесь отвлечь интервьювера интересной историей из жизни, лучше сфокусируйтесь на тех задачах, которые он перед вами ставит.

Некоторые интервьюверы не просят написать кусочек кода, но в вопросе подразумевают, что это было бы лучшим ответом. В этом случае, лучше спросить. Также можно поинтересоваться отношением интервьювера к коду – будет ли он переживать по поводу того, что синтаксис не везде будет соблюдаться? Некоторые интервьюверы равнодушны к синтаксису, полагая, что главное это общее понимание решения и алгоритм. Другие же, напротив – придираются к пропущенной точке с запятой или незакрытой скобке. Но не стоит и сразу бросаться в бой, писать код, даже если вы знаете правильный ответ. О вас может сложиться мнение, что вы сразу беретесь за реализацию, игнорируя этап проектирования. Лучше спросить.

В качестве одного из советов для технической подготовки к собеседованию, автор далее дает совет получить техническое образование. Я, как человек обладающий подобным образованием, могу с уверенностью заявить – в нашей стране это вовсе необязательная вещь. Еще ни на одном из собеседований, на которых мне довелось побывать (а их уже наберется с два десятка), меня не спросили о моем высшем образовании. Единственный раз меня спросили пару лет назад – не являюсь ли я студентом и если да, то буду ли брать отпуск на время сессии… Все.

Интересным и несколько необычным мне показалось еще и то, что в Гугле проверяют базовые знания математики. Вообще-то не только в Гугле, но и в Мелкософте такое практикуют, просто я никогда не слышал о подобных вопросах при приеме на работу в украинские ИТ-компании.

Операционные системы. Большинство интервьюверов спрашивают в основном фундаментальные вещи: что такое процесс, потоки, какие ресурсы им необходимы, как работает переключение контекста, как происходит инициализация операционной системы и подключенного оборудования, что такое concurrency issues и т.п. Также вы должны знать, что такое locks, симафоры и мониторы и как они работают. Могут спросить, что такое deadlocks и livelocks и как их избегать.

Лучшая книга, которую я прочитал на эту тему – Concurrent Programming in Java Дуга Ли.

В некоторых компаниях меня спрашивали не только о различных семействах операционных систем(MacOS, Linux, Windows), но и отличия версий в одном семействе (Windows XP и Windows Server 2003).

Языки программирования. Вы должны знать хотя бы один язык программирования хорошо и лучше всего, если это будет С++ или Java. С# тоже подойдет, так как он похож на Java. И вы должны быть готовы написать идеальный кусок кода на этом языке.

Честно говоря, я думал, что к этому списку еще добавиться Perl. Но автор оставил его почему-то без внимания.

Итак, предупрежден – значит, вооружен! Но даже если после такой подготовки вы не прошли собеседование – не расстраивайтесь, ведь всегда можно попробовать еще раз (…через полгода).

Ссылки по теме

Одна история неудачного собеседования в Гугл

Записки русского программера из Гугля

How I Blew My Google Interview

My interview experience with Google

My interview at Google

Google's Interview Questions

Google Top Interview Questions ( around 30 With Solutions)

Google Interview for Freshers

Не важно занимаетесь ли вы фрилансом или работаете на большого дядю, но если вы разрабатываете программные продукты, то у вас наверняка есть заказчик. А его, как известно, тяжело найти и легко потерять. Ниже приведены 5 типичных ошибок, которые, зачастую приводят к потере заказчика:

#1 Правильно ли вы поняли суть проекта?

Заказчики народ ленивый, а потому добиться от них подробной документации или спецификации будущего проекта непросто, особенно если проект небольшой. Зачастую менеджеры проектов получают, так называемую, user story. Потом этот документ усилиями менеджера или кого-то еще эволюционирует в спецификацию – более подробный документ с техническими терминами. И вот тут есть риск совершить первую, а зачастую и роковую ошибку – не поделиться этим документом с заказчиком. Ведь заказчик под словом “usability” имел ввиду не квадратную, а круглую кнопку! В лучшем случае такое недоразумение выльется вам в пару лишних часов работы, а в худшем – превышение бюджета/времени проекта, потеря/отказ от заказчика. Поэтому даже если вы и не планировали составить что-то похожее на спецификацию, то по крайней мере выслать скриншоты аналогов или описание проекта своими словами – было бы хорошим шагом в сторону от этих граблей.

#2 Не слишком ли часто, вы общаетесь с заказчиком?

Согласен, несколько противоречивый момент. В предыдущем пункте я рекомендовал дополнительно общаться с заказчиком, а теперь намекаю на то, что это не всегда полезно. Это действительно так. Наиболее плотное общение полезно в начале проекта, когда каждый участник, в том числе и заказчик пытаются понять и “построить” проект у себя в голове. Но дальнейшее общение по 2–3 часа в день может губительно сказаться на проекте, ведь во время этих дискуссий у заказчика появляются множество новых идей, не предусмотренных ни бюджетом, ни архитектурой проекта. Ежедневные вопросы “А в каком состоянии сейчас проект?”, “А кто над чем работает в данный момент?” и т.д. не только вызывают раздражение, но и отнимают и без того драгоценное время. И даже если заказчик отвлек вас всего на мгновение вопросом “А как пройти в библиотеку?”, то вам понадобиться от 10 минут до часа времени, чтобы вернуться в рабочее русло и восстановить свою производительность. Поэтому, если вам позовляет ситуация, ограничтесь общением по почте, оставьте номер телефона на пожарный случай – и никаких мессенджеров! Тем не менее онлайн общение необходимо на любом проекте – организуйте это в виде заранее спланированных коференц-звонков или собраний с точным регламентом по времени.

#3 Позволяете ли вы заказчику саботировать проект?

Заказчик может саботировать проект множеством способов – вносить в проект новые идеи или функционал; указывать вам как именно необходимо реализовывать ту или иную часть проекта; сокращать сроки сдачи работы и так далее. Был у меня один проект, на котором мы выполняли любую прихоть заказчика, крутили архитектурой проекта так, что через месяц ее было просто не узнать. А сам проект из узконаправленного решения превратился в некую платформу для решения “всех” проблем, в том числе и глобального потепления. Во время этого процесса заказчик был доволен как слон таблеткой, но как только подошло время первой бета-версии – он взгрустнул… Взгрустнул оттого, что бета не вышла, ведь последний месяц мы писали не запланированный функционал, а переделывали проект под новые идеи заказчика. В итоге все остались в проигрыше – мы без заказчика, заказчик – без продукта. Мораль проста – научитесь говорить НЕТ, даже если вы хотите угодить вашему клиенту.

#4 Дело дошло до спора?

Не все заказчики обладают техническими знаниями, но почти все уверены, что они умнее вас. Именно поэтому деньги платят они, а не наоборот. Спроить в такой ситуации довольно тяжело – кто платит, тот и заказывает музыку. Но что, если это может привести к краху проекта и заказчик вместо джаза получит рок? Мне не раз приходилось наблюдать, как специалисты с многолетним опытом шли наповоду у заказчика лишь бы не брать всю ответственность за долю проекта на себя. Но в итоге заказчик все равно обвинял их, когда проект начинал разваливаться на части… Идеальным вариантом будет найти третий источник информации, желательно довольно авторитетный, который бы подтверждал ваше мнение или предложение. Но если вам всеже пришлось согласиться с заказчиком, то постарайтесь сразу перенести ответственность за это решение на него и объяснить каким образом это может отразиться на проекте в будущем.

#5 Что вы делаете, когда клиент недоволен?

Пытаетесь оправдаться? Перенести вину на заказчика? Доказать, что всему виной фаза луны? Все это, безусловно, пути решения проблемы, по которым иногда приходится идти. Но зачастую, наилучшим способом вернуть заказчика в прежнее, довольное состояние – это показать, что вы с ним одна команда и находитесь по одну сторону баррикад и, что вы заинтересованы в решении возникшей проблемы не меньше его самого. Даже если бюджет уже исчерпан, время подходит к концу, то фраза “да, это проблема, но мы поможем вам ее решить” заставит смотреть на вас с благодарностью. А следующая фраза “…но на это нам нужны будут новые $” будет звучать не так удручающе, как фраза “это не наша, а ваша проблема. Денег больше нет, помочь ничем не можем.”

И что с того?

Описанные выше ошибки при работе в сфере ИТ, безусловно, не покрывают и сотой доли тех граблей, на которые многие из нас наступают ежедневно. Поэтому важно не только видеть те ошибки, которые вы совершаете при работе с заказчиками, но и уметь их анализировать. Смотрите под ноги, господа технари, и приятной рабочей недели!

Именно так – The Bug – называется "новая" книга Ellen Ullman. Не буду пересказывать содержание книги, просто оставлю две фразы из этого произведения искусства:

"Programming starts out like it's going to be architecture-all black
lines on white paper, theoretical and abstract and spatial and
up-in-the-head. Then, right around the time you have to get something
fucking working, it has this nasty tendency to turn into plumbing.

...

It's more like you're hired as a plumber to work in an old house
full of ancient, leaky pipes laid out by some long-gone plumbers who
were even weirder than you are. Most of the time you spend scratching
your head and thinking: Why the fuck did they do that?"

Как это ни парадоксально, но многие из нас работают для того, чтобы не работать. То есть стараются заработать столько денег, чтобы нужды работать больше не было. И дело тут совсем не в человеческой лени или в тяге получить статус богатого человека, а в стремлении заниматься тем, что нравиться. Тем не менее, придя на «нелюбимую» работу многие из нас все же делают то, за что им платят деньги – работают. Так откуда же берется это сокровенное желание поработать? Можно ответить просто – человеком движет инстинкт самосохранения, и в условиях рыночных отношений, для выживания необходимо где-то брать деньги. Все это верно, но есть один момент – даже движимый инстинктом самосохранения человек разумный(homo sapiens), придя на работу зачастую, лишь делает вид, что работает или, по крайней мере, осуществляет ее не в том объеме, в котором хотелось бы.

Многие компании вводят гибкий график, организовывают обеды, комфортно обустраивают офисы и многое другое только ради того, чтобы вам было приятнее работать. Делают они это не ради вашей широкой улыбки, а для того, чтобы вы лучше работали и не думали менять работу. Но правда в том, что ваша продуктивность практически не зависит от вашего настроения. Еще в далеком 1964 году Victor Vroom определил: настроение/продуктивность = 0,14. Это означает, что лишь 2% результата вашей работы были получены «благодаря» вашему хорошему настроению.  Но это вовсе не значит, что люди будут лучше также работать в условиях, приближенных к тюремным (хотя в Советском Союзе считали иначе…). Ведь обиженный или даже злой сотрудник может организовать настоящий саботаж на работе. Тут важна золотая середина – необходимо создать приемлемые условия труда и сконцентрироваться не на том, как улучшить настроение сотрудника, а на том, как увеличить его продуктивность:

Гибкий график. Позволяет сотруднику чувствовать себя свободным в своих действиях и самому строить свои рабочие планы. Абсолютная свобода в графике может привести к тому, что графики нескольких сотрудников не будут совпадать, и если их работа взаимосвязана, то продуктивность команды может пострадать. Как один из вариантов выхода из данной ситуации – зафиксировать хотя бы 4 часа рабочего времени.

Социальная или медицинская страховка. Тяжело сказать, влияет ли этот пункт соцпакета многих IT-компаний на продуктивность сотрудника…

Английский. Как один из видов профессиональных тренингов в IT-индустрии, это бесспорно положительно сказывается на продуктивности сотрудников.

Питание. Врядли «лишние» $3-$4 в день повысят продуктивность сотрудника. Более того, после определенного срока, сотрудник будет воспринимать это, как должное и не дай вам бог попытаться забрать у него эту «сладость».

Спортзал. Здоровый сотрудник работает лучше, чем больной – это факт. Но тут важно не просто выделять деньги на спорт, но и как-то мотивировать сотрудников заниматься спортом. Одна, знакомая мне компания, проводила следующую политику: сотрудники, которые не занимаются регулярно спортом, рассматриваются в качестве кандидатов на премию в последнюю очередь.

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

К сожалению, многие IT-компании на рынке Украины не могут себе позволить посылать сотрудников на дорогостоящие профессиональные тренинги, выделять время на самообучение (или собственный проект, как это делает Google) или постоянно обновлять рабочие инструменты программистов. Проще нанять уже более квалифицированного, хоть и более дорого сотрудника. Но как говорил Dietrich Bonhoeffer: "If you do a good job for others, you heal yourself at the same time, because a dose of joy is a spiritual cure." - будем трудиться и все будет хорошо.

    Вы собеседуете кандидатов на одну из вакансий в вашей компании. Кого вы пытаетесь разглядеть в этих людях? Большинство менеджеров на подобный вопрос отвечают: трудолюбивого, настойчивого, уверенного в своих знаниях и ответственного. Замечательные слова! И как после такого набора характеристик можно взять не того человека? А ведь умудряются… Дело в том, что все эти черты, вовсе не являются гарантом хорошей производительности сотрудника.

    Мы знаем, что люди ведут себя по-разному в различных ситуациях, и мы склонны разделять людей по их характерным особенностям и способам поведения. Во время собеседования менеджер/технический специалист слушают и наблюдают за кандидатом, чтобы определить обладает ли он необходимым набором знаний или нет, уверенно ли он отвечает на вопросы, как будет вести себя в различных ситуациях.

- Проект имеет старую и громоздкую архитектуру. У вас есть задача, вы можете написать красивый код за 40 часов (придется переписать плохие участки старого кода), либо написать коряво (но работать будет) за 15 часов. Как бы вы поступили?

    Все это здорово, но он пытается оценить будущего сотрудника в  текущий момент времени. При таком подходе к оценке кандидата, существуют две проблемы.  Первая – собеседование имеет, как правило, большое значение для собеседуемого, а это значит, что его поведение не будет естественным. Вторая – человек, так или иначе всегда пытается приспособиться к окружающей среде, т.е. он может проявлять нехарактерные для него черты характера на собеседовании.

- Я пишу код всегда правильно и красиво, ведь дурно «пахнущий» код – источник багов.  – скажет вам кандидат, пытаясь произвести на вас впечатление правильного сотрудника. В чем-то он прав, но вы-то не это хотели от него услышать, верно?

    Этим вопросом вы пытаетесь заинтересовать кандидата реальной, живой задачей и посмотреть на его рекацию. А кандидат в свою  очередь пытается вам понравиться и доказать, что он достоин этой работы. У вас разные цели, а значит, успех вашего сотрудничества стремительно приближается к 0.

    Так как же оценить кандидата? Попробуйте дать оценку не тому, как бы он поступил, а тому, как он поступал в различных ситуациях. Расспрашивая о прошлом кандидата, вы возвращаете его в старый, привычный для него офис, усаживаете в любимое кресло, с отломанной левой ручкой и «подаете» горячий, пусть и дешевый, ароматный кофе. И кандидату уже не нужно напрягаться, придумывать, как бы выкрутиться из вновь сложившейся ситуации. Он просто рассказывает вам о своем опыте и говорит, как было. Только выводы вам теперь сделать сложнее – приходится читать между строк, но это уже тема другой статьи…

    Таким образом, вопросы ориентированные на прошлое кандидата расскажут вам больше, чем искусственная, смоделированная ситуация на собеседовании.

Факт #1: При взлете с воды, каждый гусь бьет крыльями по поверхности воды, таким образом стая формирует воздушный поток, который облегчает взлет отдельно взятой особи на 71%.

Вывод: Группа людей, разделяющая общие цели и возможности, достигает результата быстрее за счет того, что каждый опирается на сильные стороны другого.

У меня был опыт работы в нескольких командах разработчиков. Опишу лишь две из них:

1. Первая команда состояла всего из 3–х участников. Это неплохие, умные и скромные ребята. У каждого участника был огромный опыт работы с необходимыми технологиями. Но прежде эти люди вместе никогда не работали.

2. Вторая команда состояла уже из 4–х участников-новичков, и о них можно было сказать следующее: настоящие товарищи, хотя раньше им вместе работать также не приходилось. Работа в этой команде всегда была оживлена беседами “не по работе” и в компании этих людей было просто приятно находиться.

Артем Попов. © «Ашманов и Партнеры»

Задачи у обеих команд стояли разные, поэтому сравнивать производительность команд нецелесообразно, но могу сказать следующее: первая команда не достигла своей цели. Это произошло потому, что один из участников полагал, что у него достаточно опыта для решения поставленной перед ним задачи. Он никогда не обращался к товарищам за помощью и в итоге затянул проект. Второй же участник, узнав о срыве сроков попросту бросил проект, т.к. задержка не входила в его планы. Проект так и не вышел в свет.

Вторая команда своей цели тоже не достигла, но причины для этого у нее были другие: продукт, который она выпустила, кстати сказать всрок и с оговоренным функционалом – было невозможно продать т.к. мы выбрали неверную модель продаж.

Хотя мой опыт участия в обеих командах и оказался негативным, но с тех пор я предпочитаю команды 2ого типа – команды товарищей, а не группы супер-звезд. У команды товарищей есть шанс достичь цели, если в команде есть лидер, ясно представляющий себе цель и средства ее достижения. У первого типа команд – шансов нет – каждый из участников представляет собой бомбу замедленного действия. Хочу также заметить, что редко встречаеются команды супер-звезд, между которыми по-настоящему дружеские отношения. В моем понимании – это идеал команды.

Факт #2: Гуси никогда не нарушают строя во время полета, потому что знают – в противном случае, сопротивление воздуха на каждую особь увеличится и стая скорее всего не долетит до цели – сил не хватит.

Вывод: Если участники команды двигаются в одном направлении, но с различными целями, то есть риск не достичь даже своей цели, не говоря уже об общей.

Приведу еще один пример из своего личного опыта. В то время жизнь казалось трудной, но и захватывающе интересной, впереди было много тяжёлой работы и грандиозных задач. Перед нашей командой была поставлена цель – реализовать модуль одного большого проекта, причем в срок. В моей команде тогда работали два программиста. У каждого из них были цели, о которых я даже и не подозревал. Целью первого, назовем его Богач, было заработать как можно больше денег, поэтому он с удовольствием соглашался на работу в овертайм. Целью же второго – Идеалиста, было написание совершенного кода, этот человек всегда и во всем стремился к идеалу. Моей же целью было – выполнить проект в срок. События развивались далее следующим образом: Богач делал работу неспеша и к идеалу в коде особо не стремился – а зачем? за это больше не платят… Идеалист же наоборот – переписывал свой код по-нескольку раз, вызвая задержки со сдачей своих задач. Я, не подозревая о целях каждого, старался сделать каждую задачу как можно быстрее и по-возможности без багов . Как вы понимаете, сроки мы сорвали.

Опыт опять отрицательный, но все же опыт. Если бы я знал о целях каждого из участников и имел возможность распоряжаться бюджетом проекта, то в качестве одного из вариантов решения этой задачи можно рассмотреть следующее: уменьшить ставки разработчиков и ввести премиальную систему с идеологией – чем быстрее сделал(с определенным процентом багов), тем больше заработал. Этим можно было бы достичь большей производительности от Богача и пересмотра своих амбиций у Идеалиста.

Факт #3: Когда гусь-лидер устает(он ощущает наибольшее сопротивление воздуха), то он занимает место в конце строя, а на его место становится другой.

Вывод: Имеет смысл разделять любую трудную/нудную работу между всеми учатниками команды. Также полезно разделять и лидерство.

Артем Попов. © «Ашманов и Партнеры»

Компания, где наша команда работает в данный момент занимается самыми различными проектами. В том числе и проектами на старых технологиях. Конечно же никому не хочется вспоминать ASP.NET 1.1 и разбираться в багах старого проекта. Но эффективная командая работа – это постоянное динамическое равновесие между общими потребностями команды и личными потребностями ее учатсников. Быть среди людей и работать вместе с ними – здорово. Но все мы, каждый из нас, все равно хотим быть Номером Один. Забудьте обо всех этих киношных сценах, где солдаты бросаются грудью на амбразуру, чтобы защитить своих товарищей. В реальной жизни мы сотрудничаем с другими в первую очередь ради того, чтобы удовлетворить свобственные потребности. Люди соглашаются работать в команде только при словии, что в первую очередь это поможет им удовлетворить собственные потребности.

Конечно же, некоторые согласны отсрочить удовольствие. Это, в некотором смысле, мазохисты, которые готовы достигать целей команды в обмен на какие-то выгоды в будущем. Такие люди стойко переживают сегодняшние невзгоды, чтобы получить вознаграждение завтра.

Факт #4: Гуси, летящие в строе, всегда кричат, если впереди летящие сбавляют скорость. Таким образом поддерживается строй во время полета.

Вывод: Участники команды должны прислушиваться друг к другу, чтобы знать что они двигаются в правильном направлении.

В одной из компаний, где мне довелось работать раньше, был такой случай. Стоял теплый июнь месяц, все прятались за плотными жалюзями и в обществе кондиционеров. Вот только комната, где сидела наша команда, располагалась таким образом, что солнце никогда не скрывалось у нас из виду, раньше чем наступала ночь… Именно тогда нам и пришла в голову мысль, попросить у руководства денег на жалюзи и кондиционер. Это происходило примерно следующим образом:

– Нам жарко, поставьте нам кондиционер и повесьте жалюзи. 

– Эмм, а у нас не жарко. Да и зачем вам сразу жалюзи и кондиционер? Выберите что-то одно.

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

– Хм, мы вас конечно понимаем, но деньги кончились…

(тем временем наступил знойный июль и мы заклеили окна газетной бумагой).

– Как там с деньгами? Появились? У нас техника отказывает, но коллектив – держится.

– Денег по-прежнему нет. Молодцы, что держитесь. А тяжелые времена пройдут. (хотя жалюзи нам, после приезда одного из менеджеров, всеже повесили)

Казалось бы, условия труда – это то, на что большие компании(а компания была ооочень большая) тратят деньги легко и всегда, но нет – компания предпочла выкупить еще два соседних помещения на “перспективу”…

(прошел июль, а за ним и август. Наступила ласковая осень)

– Ха! Просили кондер – а мы вам никогда не откажем. Нате – получите.

– ???

– Все ради сотрудников, все ради вас.

Хоть наши просьбы в конечном счете были выполнены, но авторитет руководства уже был ниже ватер-линии и один сотрудник успел покинуть нашу команду.

Факт #5: Когда один гусь заболевает или получает ранение, еще двое его товарищей покидают строй и следуют за ним, чтобы помочь или защитить раненного. Они находятся с ним до тех пор пока он либо не умрет, либо не выздоровет. После чего они либо присоединяются к следующей стае, либо догоняют свою.

Вывод: Друг познается в беде…

Артем Попов. © «Ашманов и Партнеры»

P.S.

Иллюстрации к данной статье были скромно позаимствованы у Артема Попова из книги Ашманова “Жизнь внутри пузыря”. Кто еще не читал – настоятельно рекомендую. Книга будет очень полезна менеджерам, да и просто участникам каких-либо сообществ. Одним словом – всем.

Началось все очень давно – еще во времена первобытного человека. Будучи homo sapiens, первобытный человек заметил, что вместе с другими людьми выжить легче, чем в одиночку. Как далее развивались события - вы знаете из курса истории. Люди начали объединяться в общины, потом племена и так появилось государство. Но во все времена были группы людей имеющие схожие интересы или цели, именно интересы и цели объединяют людей в профессиональные сообщества или “тусовки”. Некоторые гуру менеджмента отмечают постепенный переход от разделения людей по классовому и территориальному признаку, к делению на сообщества и “племена”.

Связи решают все. Не имею 100 рублей, а имей 100 друзей. Рыбак рыбака видит издалека.

Чего каждый из нас мог бы добиться без содействия друзей, знакомых, близких и других окружающих близких людей. Не знаю как вы, но я бы точно не был там где нахожусь, без помощи родителей и друзей.

Как это ни цинично звучит, но каждый из нас товар на рынке труда. Точне не мы, а наши умения, навыки, опыт и деловой имидж. Нас продвигают, а проще гвооря продают родные и близкие, друзья и сообщества. Обычный рассказ в курилке о вас, с оценкой “+” или “-”  может сыграть большую роль в вашей судьбе профессионала. По статистике получив о вас положительный отзыв, ваш собеседник передаст эту информацию пяти своим знакомым, а получив негативную – десяти! Лучше конечно производить приятное впечатление на любого собеседника, работая тем самым на свой имидж или бренд. В любой профессиональной среде настоящие специалисты продаются не через рекрутеров, а через знакомства. И то как вас продадут зависит от того, что о вас говорят коллеги.

Становится модным понятие личного бренда или создание своего образа. На сегодняшний день ваша конкурентноспособность построена на вашей компетенции, а именно на ваших знаниях и умениях, которые вы сможете применить на практике.

Рубаха – парень. Жмот. Эгоист

Обратите внимание, в своей жизни мы сталкиваемся со многими брендами: CocaCola, Microsoft, BMW. Также мы видим бренды личностей: BillGates, Mikel Jackson, Michael Schumacher и другие. Причем если раньше бредны личностей были характерны для деятелей шоу-бизнеса, политических деятелей и ученых, то теперь это понятие распространяется и на лучших специалистов в своих областях.

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

Алгоритм построения бренда не так сложен:

Первое, что вам предстоит сделать это установить области, где ваши умения и навыки можно применить – т.е. определить рынок сбыта себя, как товара.

Второе, вам необходимо постоянно быть в курсе событий в выбранной вами области, давая чуть больше потребителям, чем это требует от вас окружение. К примеру, вы программист. И менеджер просит вас дать примерную оценку каких-либо работ. Можно прикинуть, что это займет примерно два часа и накинуть еще два часа на случай непредвиденных обстоятельств, таких как внезапная встреча с роскошной секретаршей в корридоре и совместное распитие кофе за милой беседой. А можно дать оценку задач поэтапно, сопровождая комментариями о том, какие риски вы в каждой из подзадач видете: сложная техническая реализация, возможная несовместимость версий продуктов, недостаточность информации и тп.

Третье, очень хорошо когда у вас есть свое портофлио: примеры уже сделанных работ, сертификаты, рекомендательные письма. Большое значение играет стиль одежды, прическа, деловые аксессуары и т.п. Очень важно чтобы ваш стиль соответствовал(но не копировал!) стилю, принятому в вашей профессиональной среде.

Четвертое, будьте на виду. Встречайтесь, общайтесь, приходите и приглашайте. Видите активную жизнь, не забывая о своих целях.

Пятое, очень важно как вы умеете разговаривать публично. Не только перед своими тремя лучшими друзьями в курилке(хотя это тоже важно), но и перед совершенно незнакомой публикой. С этим умением не рождаются – его воспитывают в себе сами. Возможно позже я напишу пару статей на эту тему

Шестое, многое зависит от вашей индивидуальности и уникальности. Необходимо проявлять уважение исходя из своих личных ценностей. Если вы активны – подарите клиенту энергию, если уравновешенны – подарите уверенность.

Казаться, чтобы быть или быть чтобы казаться?

Ни для кого не секрет, что реклама зачастую преукрашивает действительность, если даже не нагло врет. Даже если это реклама самого себя. Так что мне нагло врать каждому встречному, что я супер-специалист? Конечно же нет. Врать не хорошо. Но рассмотрим такой пример, студент закончил университет и пытается устроится на работу. Ему задают такой стандартный вопрос: “Какой у вас опыт работы?”, на что он естественно отвечает: “Никакого. Но я хорошо учился.”, после чего работадатель проникается к нему глубокой жалостью и отказывает в устройстве на работу… Если бы студент сказал, что он имеет огромный опыт работы, то через 5–10 минут собеседования стало бы ясно, что такового опыта у него нет и в его протоколе собеседования была бы строчка: “Переоценивает свои силы” или “Соврал об опыте работы”. К слову сказать такие протоколы собеседования или анкеты ведут и сохраняют многие компании для последующей их обработки. Благодаря этим анкетам можно увидеть рост человека за определенный период времени, а также это лучший способ вести мониторинг рынка труда. Так что же нужно было ответить? К примеру, “опыт работы у меня небольшой: я делал маленький проект для группы Х и пытался его продать, но ничего не вышло и я пришел в вашу замечательную компанию…” В итоге, студент получит не только работу, но и шанс стать специалистом. Да и работодатель не останется в проигрыше – если человек не будет справляться со своей работой, то его попросту уволят, а если начнет расти профессионально – то руководство хорошо заработает на этом сотруднике.

Кстати умение проходить собеседования это тоже отдельная тема, которую я освещу позже.

Online “тусовки”

Думаю объяснять, что такое социальные сети не стоит. Хотя польза от них, на данный момент, меньше чем от привычных нам курилок и уютных кафе, но тем не менее они позволяют продавать себя не только в вашем родном городе(стране), но и зарубежом. В одну из таких социальных сетей затянуло и меня.

Продолжение следует…

В последнее время мне довольно часто приходится оценивать различные проекты, которые рассматривает компания в которой я работаю. И я хочу поделиться опытом оценки еще не созданных программных продуктов. Итак, что же необходимо для того чтобы правильно оценить трудозатраты на проект? 

• Первое и самое главное - это безусловно опыт, потому что если вы уже реализовывали подобное в ваших предыдущих проектах, то вероятность того что ваша оценка совпадет с реальностью увеличивается.
• Далее необходимо  разбить будующий функционал на как можно более независимые блоки их можно разрабатывать в различных фазах проекта.
• Затем каждый блок разбивается на функционал, время реализации котрого не более 3х часов.
• Если какие-либо части настолько сложны или новы для вас, что вы не представляете себе как их реализовывать, то лучше потратить час-два на изучение/поиск подобных решений в гугле. Кстати,забыл сказать, что прежде чем вообще садиться оценивать проект, можно посмотреть не реализовывал ли кто-то другой, то что вы сейчас пытаетесь создать. Свой опыт ценне всего, но если есть чужой, то почему бы им не воспользоваться?
• Еще один момент - оценивать проект лучше не в одиночку(какой бы вы гуру ни были), а небольшой группой в 2-3 человека. Если количество людей будет больше, то будет слишком много мнений и тяжело будет быстро прийти к компромиссу, а следовательно быстро оценить проект (за оценку проекта заказчик как правило не платит...). Если людей будет меньше, а именно вы один, то есть риск переоценить или недооценить собственные силы.
• Но даже разбив проект на мелкие части и оценив каждую из них, мы не сможем получить точную оценку проекта(честно говоря получить точную оценку проекта невозможно в принципе), так как еще необходимо учесть человеческий фактор, а он предполагает чтот в рабочем 8ми часовом дне вовсе не 8 часов отдается работе:

  - Чтение блогов и новостей, разгребание почты по утрам. (15 минут в день)

  - Перерывы на кофе/чай. (2-3 в течении дня 10 минут на каждый)

  - Различного рода собрания. Проектные собрания для решения текущих вопросов. (дважды в неделю 3 часа)

  - Решение проблем с железом, не работает комп или сеть или нет тока. (раз в две недели пол дня)

  - Мелкие проблемы с ПО (не грузится студия, поставился патч после которого винда перестала адекватно работать). (дважды в неделю по часу)

  - Заполнение time journal-ов и других формальных документов. (15 минут каждый день)

  - Походы в WC. Да, это тоже занимает время. (10 минут в день. В дни когда селедку запиваешь с молоком 10 минут каждый час ;)

  - Написание необходимых емейлов (4 часа в неделю)

  - Написание ненужных емейлов (4 часа в неделю)

  - Удаление спама (30 минут в неделю)

  - Болезни, прочие личные причины отсутсвия на работе (1 день в месяц)

  - 8 минут - одна сигарета

• Для подсчета времени на вышеупомянутые радости жизни можно либо подсчитать в столбик либо воспользоваться принципом трех четвертей: берем четверть времени от общей оценки проекта и прибавляем ее к оценке - таким образом закладываем время на разработку новых или измененных заказчиком требований. Затем от этой четверти считаем четверть и опять прибавляем к общей оценке(убираем риск преодоления "подводных" камней в проекте) и наконец от последней четверти прибавляем четверть и таким образом закладываем время на все те радости жизни, что я описал пунктом выше.