Воплощение большинства бизнес-проектов требует широкого спектра навыков и знаний. Если вы руководите таким проектом, то практически обязательно вам приходится управлять группой представителей разных профессий. Они могут быть частью вашей организации, представлять различные подразделения вашей компании или работать в совсем отдельных структурах. Откуда бы они ни были, они объединены в то, что называется «межфункциональной» или «кросс-функциональной» командой.

Как менеджер проекта, над которым работает команда, вашей задачей является организация членов команды с тем, чтоб превратить их эффективную и слаженную группу специалистов, способную достичь целей, поставленных перед проектом. Сложная задача? Бесспорно, сложная — даже запутанная и трудоемкая. Однако, если следовать определенным правилам, сплочение команды может стать вполне благодарным занятием, а также более легким и вполне успешным. В этой статье изложены самые основные моменты.

Что необходимо знать

Я новичок в менеджменте проектов и мне необходимо сформировать кросс-функциональную команду. С чего мне начать и как найти подходящих людей?

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

Как разработчик, вы сидите на золотой жиле. Вы осознаете это?

Нет, серьезно, на @#$% золотой жиле! Никогда в истории не существовало возможностей так легко создать что-то с нуля, с маленьким или отсутствующим начальным капиталом и маркетинговой моделью, ограниченной только вашим воображением.

Подумайте о крупнейших сайтах, которые вы постоянно посещаете: Facebook, Twitter, Flickr, Foursquare, или даже Google — все они были созданы разработчиками, у которых была лишь идея. Было ли это легко? Черт, нет. Но это могло быть сделано только в наше время. Так, черт побери, почему вы просиживаете день за днем, работая на кого-то?

Предисловие

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

Будучи программистом я многое узнал о том, как создаётся программное обеспечение. Вот несколько фактов, которые могут вас удивить.

Возможно ли создание по настоящему Открытой студии для совместной реализации веб-проектов?

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

Работал в закрытых студиях и сотрудничаю с ними сейчас в качестве фрилансера. При этом ни сотрудничество с «обычной» студией, ни самостоятельное исполнение заказов не считаю правильным…

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

Итак, Открытый процесс работы над проектом. Какой он?

Всем привет,
Предлагаю обсудить одно из возможных решений проблемы 20/80, реально используемое в нашей компании.

Многим менеджерам проектов известен закон Парето (в общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»), в нашем варианте «на последние 20% проекта требуется 80% ресурсов». Проще говоря, проект по настоящему начинают делать за 3 дня до открытия. В результате: аврал, срыв сроков, низкое качество, беготня, стресс и прочие удовольствия PM'a.

Частая ошибка – дать разработчикам ТЗ и ждать пока они все сделают, а потом начать проверять. Это работает, когда проект очень маленький. Значит, надо из одного большого проекта сделать несколько маленьких. Путем проб и ошибок для себя мы нашли решение, которое условно назвали «недельные итерации» (хотя это не итерации в полном смысле, когда каждая итерация это мини-проект, включающий все фазы, от анализа до внедрения) — задачи объединяются в итерацию так, чтобы они могли быть выполнены за неделю. Теперь самое важное — итерация должна быть сделана полностью и проверена.

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

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

Предисловие

Хорошо, когда работаешь с человеком, который отлично знает толк в своём деле. А что, если случается работать с коллегой, опыт которого не столь большой. Особенно это касается профессионально-личностных качеств. Невольно приходится подсказывать, местами помагать ему, а где-то даже откровенно учить. Все мы когда-то начинали. Все эти действия требуют немалых усилий, которые можно было бы применить по прямому назначению — в разработке проекта, но без подготовки новых специалистов будет тяжелее.

Так вот, чтобы минимизировать эти затраты, давайте «создадим» хорошего, а возможно и идеального начинающего программиста, с высоким потенциалом и светлыми горизонтами.

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

1. Будьте самостоятельными

Если у вас есть какой-то вопрос, и вы не знаете как с ним поступить, то вначале постарайтесь исследовать его самостоятельно. Не ждите постоянной помощи от коллег — у них и без вас работы хватает. Используйте всю мощь поисковых систем, специализированных ресурсов (например, stackoverflow), профессиональных блогов, форумов разработчиков, и конечно же хабра. Большинство типичных «граблей» можно обойти различными эффективными вариантами, а для решения базовых задач есть дюжины готовых решений. Просто пойдите и возьмите.

Перевод статьи Тима Ферриса из его блога.


(Учебник Дзюдо Окано Исао, который я использовал для изучения японской грамматики)

Изучение языка не должно быть сложным.

Принципы когнитивной нейронауки и управления временем могут быть применены для достижения свободного владения языком на разговорном уровне (в данном случае определяется как 95%+ процентов понимания и 100% выразительных возможностей) в течение 1-3 месяцев.

Прогресс не стоит на месте, люди ищут новые решения, и на JVM появляется всё больше интересных языков. Но «ядро» JVM сообщества — народ суровый, привыкший к серьёзным стандартам, и с высокими требованиями. Поэтому большинство новых языков так и висят «на периферии».

От других языков на JVM Scala отличается действительно основательным подходом — над языком работает лаборатория мощнейшего европейского института EPFL во главе с профессором Мартином Одерски, который также известен как дизайнер системы generic-ов из Java 1.5. Конечно, это не сравнить по объёму поддержки с серьёзными коммерческими конторами в роде Sun или Microsoft, поэтому язык развивался медленно и «пошёл в дело» совсем недавно:


Что в нём интересного?

Всем привет,

Собираюсь поделиться с вами технической стороной того, как я за 16 недель сделал новый вебовый rss ридер, и чуть не сошел с ума.
Отходя от долгой предыстории, будем считать, что все началось в феврале этого года, когда мы с Дэвидом (dmiloshev, UI-дизайнер) решили сделать прототип нашего детища вдвоем.
«В одиночестве» — потому, что не было никаких скрамов, совещаний, «коллективного разума», а всю техническую часть, довелось делать самому.

Если бы меня попросили описать всю статью в одном предложении, то получилось бы:
No-SQL, mongodb, node.js, фак мой мозг, Evented I/O, очереди, выводы, git, nginx, memcached, Google Reader, Atom, TTL, PHP, ZF, jQuery, выводы.

По следам этого поста.

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

Я рад поделиться с вами новостью, что сегодня мы анонсировали Silverlight SDK для разработки приложений для социальной сети Мой мир@Mail.Ru. Этот продукт является плодом тесного сотрудничества компаний Mail.Ru, Microsoft и нас.

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

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

...Skype — это дьявольски хитрая программа, написанная бесспорно талантливыми людьми..._{Крис Касперски}

Доброго времени суток!

Skype сейчас я встречаю чаще на компьютерах чем другие IM клиенты, мне он практически заменил icq, вся рабочая переписка ведется в skype, но речь пойдет не о том, что лучше или популярней. Часто бывает так, что участвуешь сразу в нескольких чатах где количество участников превышает 10, что собственно и приводит к тому, что на рабочем столе и в трее постоянно обновляется количество новых сообщений, а также уведомления в виде всплывающих сообщений, а теперь представьте что у вас 3 окна чата с друзьями, 1 с вашим боссом, другой с девушкой — все это в сумме начинает запутывать, отвлекать и порой раздражать. Хотелось бы расставить приоритеты…

Раньше я чаще всего настраивал «политику» уведомлений только через глобальные настройки программы
Случилось так, что я узнал, что в каждом окне чата skype возможно использование команд, например /alertsoff отключит уведомления для конкретного окна чата, соответственно /alertson включит их обратно.
Поискав немного я наткнулся на некое how-to, оказывается у skype чата довольно много текстовых команд, подобие IRC команд. Далее я постарался попробовать все возможные из них на двух имеющихся у меня платформах, как оказалось не все и не везде работает… Прошу под кат.

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

.Net-приложения, использующие WinForms, вполне могут работать под Mono, но в некоторых дистрибутивах Linux вместо русских шрифтов пользователи видят стройные ряды квадратов и разъехавшийся интерфейс.


Изучение проблемы показало, что в разных Linux-дистрибутивах на одной и той же версии mono (в частности, 2.4.2.3) программа была как с нормальным интерфейсом, так и с квадратами. Поиски решения в интернете привели к описанию проблемы с драйвером для видеокарт Intel в Ubuntu xserver-xorg-video-intel. Десятки разных тем на англоязычных форумах, описывающих это решение с использованием последней версии драйвера. Например, здесь и здесь. При этом на практике обновление драйверов проблему не решало.
Второй по популярности совет – установить пакет шрифтов msttcorefonts тоже не помог. Однако копнув чуть в сторону, мы обнаружили, что если в программе явно использовать простые шрифты, вроде Arial, то проблема квадратов исчезает. Оказалось, что «виноват» в этом шрифт Ms Sans Serif, используемый по умолчанию для всех форм на WinForms. Судя по всему, шрифт, заменяющий его в Ubuntu 9.04, содержит кириллицу, но начиная с 9.10 этот шрифт уже без кириллицы.

Сейчас, пожалуй, только староверы в глубокой тайге не знают, что такое фриланс. Причем те из них, кто еще не отдал добычу еды на аутсорсинг. И вместе с тем, как набирает обороты движение свободных разработчиков, рождается множество забавных, а, порою, опасных религий, с этим связанных. Про одну из них мне и хотелось бы поведать. Мотиватором для этого послужила данная статья на Хабре — habrahabr.ru/blogs/pm/95548.
NB: Статья, разумеется, шутливая и позже была перенесена в ХабраЮмор, но нас ведь не проведешь и мы прекрасно понимаем, что юмор используется для того, чтобы на рынок умов могло проникнуть то, что не пустят через парадный вход. Как говориться, политический анекдот — это тоже шутка. В общем обратите внимание, что рассматривается не упомянутая статья, а религия, частным порождением которой эта статья и является..

Итак, есть такая партиярелигия: заказчик — Враг, потому что он Виноват Во Всем. Именно так, с большой буквы «В». Иногда он Гад, Мерзавец и Подонок, но в итоге он все равно Виноват. Сорваны сроки — виноват заказчик, проснулись с больной головой — виноват заказчик, молоко убежало — виноват заказчик. Любое письмо от заказчика вызывает нервный тик, звонок — приступы бешенства, а уж встреча — это ринг микс-файтинга и DeathTrack'а без каких-либо правил.

Естественно, мы любим его, когда он нас выбирает в качестве подрядчика. Воодушевляемся, когда получаем аванс и т.п. Но речь идет о тех моментах, когда проект пошел не туда, куда мы его направляли. Или не направляли, но тайно в душе надеялись, что он туда пойдет. Вот в такие периоды и проявляется наша «темная сторона» и мы начинаем искать его вину… Впоследствии различные «виноватости» группируются, сортируются и каталогизируются, рождая множество притч, легенд и статей аналогичных вышеупомянутой. Но разрешите вам представить и другую точку зрения.

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

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

В своём блоге «Android в Украине» я написал одноименную статью