Управление разработкой *

Добрый день, все хабровчане!

А давайте поговорим о западном бестселлере, перевод которого почему-то прошел незамеченным.
Речь пойдет о книге Г. Лакман Макдауэлл «Карьера менеджера IT-проекта. Как устроиться на работу в ведущую технологическую компанию».

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

Вот мои главные цели:

• не нанимать плохих работников;
• нанимать хороших работников;
• оставить кандидата с положительным впечатлением о компании.

Сегодня мы расскажем о нашем очередном нововведении — DNS-менеджере. Он построен на основе решения ANS и уже доступен для всех наших клиентов.

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

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

До сих пор, мое продвижение по карьерной лестнице было быстрым. В 2008 году, я начал работать на полную ставку программистом в должности Junior Developer. Там был славный босс и классные коллеги, и я получил навыки использования Java и .NET, вместе с первым полезным опытом. Поработав так пару лет, я чувствовал, что настало время двигаться дальше…

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

Как правило, у многих он ассоциируется с жесткими привязками ко времени и четким заранее составленным планом. Но все знают, что разработчиков нельзя загонять в рамки. Тем не менее каждый разработчик должен уметь правильно и эффективно организовать/спланировать своё рабочее время. Давайте подумаем как можно подойти к этому процессу.

Тайм-менеджмент по сути это совокупность действий по тренировке осознанного контроля над временем, посредством которого можно существенно увеличивать свою продуктивность и эффективность.

Как правильно подойти к этому процессу? Мне нравится подход в гибких методологиях разработки. Чем же они так нравятся разработчикам? Думаю, что тем, что их можно подстраивать под себя. Главная идея, из которой я предлагаю исходить — это набор правил, при этом каждый может выбирать из них те, что подходят именно ему, может дополнять, исходя из своих потребностей.

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

Для начала рассмотрим основную идею тайм-менеджмента. То есть возьмем то, что не напугает разработчика.

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



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

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


Последняя осень?

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

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

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

Вкратце в двух словах о себе и прочем чтобы пост имел некоторую большую содержательность: на фрилансе 3 последних года с копейками. Работаю не один. Команда. Объединены интернетом и рамками СНГ. Большинство никогда не видел и даже с ними ни разу не созванивался. Офиса нет. С одним из таких граждан общаюсь и работаю уже лет 5-6. Как это ни странно барьером это не послужило. Знакомых, друзей, бывший сотоварищей по работе в команде нет и никогда не было, как и не было этой самой другой работы. Да, есть и такие странные люди на свете, кто никогда не работал в офисе и ничем иным не занят и это ни разу мне не помешало, а скорее наоборот.

Как я «докатился до такой жизни» и всю иную историю, предысторию и реалии опишу как-нибудь в другой раз, если сообщество посчитает это нужным (на этот случай предусмотрен опрос). А сейчас перейдём к тому, что и было запланировано.

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

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

Заполучив что-то вроде нового супермасштабируемого молотка, горячо обсуждаемого на Hacker News, вы лупите им по всему, что попадается на вашем пути, пока каждая ваша вещь не превратится в пыль, а все, кого вы любите, не скончаются от тяжелых черепно-мозговых травм.

Переведено в Alconost.

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

Эссе Пола Грэма переведено в Alconost.

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

— Вася, так может ты сам поработаешь? Уже десять человек уволили… Понимаю, специалистов в наше время не сыскать, понимаю, одному работать трудно, но может всё-таки попробуешь, а?
— Иваныч, я бы с радостью, но кто тогда мелкими делами будет заниматься? Я пишу важнейшие вещи, а отвлекаться на пустяки всегда очень трудно. Найди мне хорошего человека, Иваныч! Я верю, однажды попадётся тот самый, который сможет работать как я, а то и лучше!
— Да что ты, Вася, я уже убедился — лучше тебя никого мне не найти. Я постараюсь, Вась, постараюсь!
Директор похлопал его по плечу и вышел из кабинета. А Вася нажал Alt+Tab и продолжил читать ленту.

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

Началось все с покупки модема Yota Many. Эта штука соединяется с сетью 4G и раздает WiFi, о ней уже написан отличный обзор на Хабре. Скорость соединения у меня дома была вполне достаточной, поэтому я купил целый год интернета за 9 тысяч. Ничто не предвещало беды…

(UPD. Перенесла в ХабраЮмор. Господа, не воспринимайте все так серьезно :-) )

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

Присылайте требования в файле Excel, а скриншоты ошибок — в Word

Разработчик — счастливый владелец рабочего компьютера образца 2005 года — получит массу удовольствия, пытаясь открыть мегабайтный файл, перекапывая все сто листов требований в поисках двух строк изменений и увеличивая масштаб просматриваемого файла, чтобы рассмотреть скриншот. Желательно также делать скриншоты максимально неинформативными, чтобы ваша приятная переписка подольше не заканчивалась. Еще можно творчески подойти к описанию проблемы, отображенной на скриншоте: лучше всего работает фраза «Посмотрите, пожалуйста!» (не забывайте смертельно обидеться на ответ «Посмотрели!»).

Сегодня на ваших мониторах продолжение мини-сериала «Разработка сайта». Нелегкому труду менеджеров посвящается!:)