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

Что я понимаю под ритмом? Развитый в себе навык вспоминать и возвращаться к тем или иным темам или вопросам спустя одно и то же время. «Рваность» работы менеджера, постоянное переключение задач, «проблемно-ориентированное» управление — яркий пример, когда этот принцип не соблюдается.

Как же обуздать этот хаос?

Во вчерашней статье я писал о шаблоне плана управления релизной разработкой.

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

Сегодня я хочу поделиться своей методикой планирования времени в разработке ПО, которая может быть очень быстро внедрена в небольших коллективах. Она очень проста во внедрении и «поддержке», чем показала себя очень эффективной.В разное время, имея разные задачи и разные ограничения в управлении разработкой, я испробовал всё: от Microsoft Project и онлайн-сервисов до «самописных» решений. У каждого варианта есть свои недостатки и преимущества, и каждый из них заслуживает отдельной статьи. Сегодня речь пойдет о наиболее простом варианте — управление релизной разработкой в Excel-е. Также я поделюсь шаблоном этого плана, который каждый может доработать «под себя».

Я продолжаю цикл статей, посвященных некоторым простым правилам разработки под Unix «по версии Эрика Реймонда», которые, по моему глубочайшему убеждению, могут быть распространены на любые другие операционные системы. Я уже рассказывал в первых трех частях о правилах модульности, ясности, композиции, разделения, простоты и кодоэкономии. Сегодня дело дошло до седьмого правила —

Правило прозрачности: проектируйте ПО сразу с учетом отладочных инструментов

Я продолжаю цикл статей, посвященных некоторым простым правилам разработки под Unix «по версии Эрика Реймонда», которые, по моему глубочайшему убеждению, могут быть распространены на любые другие операционные системы. Я уже рассказывал в первых трех частях о правилах модульности, ясности, композиции, разделения и простоты. Сегодня дело дошло до шестого правила —

Правило кодоэкономии: разрабатывайте большие программы только при наличии объективных причин это делать

Я продолжаю цикл статей, посвященных некоторым простым правилам разработки под Unix «по версии Эрика Реймонда», которые, по моему глубочайшему убеждению, могут быть распространены на любые другие операционные системы. Я уже рассказывал в первых трех частях о правилах модульности, ясности, композиции и разделения. Сегодня дело дошло до пятого правила —

Правило пятое: добавляйте сложность лишь там, где она действительно необходима (Design for simplicity; add complexity only where you must.)

Я продолжаю цикл статей, посвященных некоторым простым правилам разработки под Unix «по версии Эрика Реймонда», которые, по моему глубочайшему убеждению, могут быть распространены на любые другие операционные системы. Я уже рассказывал в первых трех частях о правилах модульности, ясности и композиции. Сегодня дело дошло до четвертого правила —

Правило разделения: отделяйте правила от механизма, а интерфейсы от движка («бизнес-логики») (Rule of Separation: Separate policy from mechanism; separate interfaces from engines)

Продолжаю цикл статей на тему «Искусство программирования под Unix» Эрика Раймонда. Ранее я упоминал первые два правила — модульности и ясности.
Сегодня речь пойдет о третьем правиле —

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

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

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

Вчера у нас завершилась выездная конференция.

Руководители отделов рассказывали про итоги последнего полугодия и о планах, близких и не очень.

Бросилось в глаза в своей массе низкое техническое качество презентаций. Не выступлений, а именно того, что при этом демонстрируется на экране. Три самых главных недостатка:

• очень мелко,
• очень много букв,
• много орфографических и пунктуационных ошибок и они грубые.

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

Для тех, у кого времени побольше, рекомендую статьи Белова (части первая и вторая). Также очень полезна статья с нашей «Хабры», 5 проверенных способов заставить аудиторию почувствовать себя идиотами, в ней с примерами показано, как делать не надо.

Продолжаю цикл статей, связанных с правилами Эрика Реймонда из «Искусства программирования под Unix».

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

Сегодня речь пойдет о следующем правиле —

Правило ясности: Ясность лучше заумности (или ясность лучше, чем мастерство)
Rule of Clarity: Clarity is better than cleverness.

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

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

Есть ряд книг, которые, на мой взгляд, являются своеобразными «библиями» для тех, кто решил связать свое будущее с разработкой ПО. С одной из них я хотел бы начать цикл статей. Это книга Эрика Рейнмонда, «Искусство программирования под Unix». Я бы рекомендовал эту книгу не только тем, кто выбрал для себя открытые операционные системы. В основе лежит довольно универсальная философия, пригодная абсолютно всем, связавшим свою профессию с программированием.

Эрик Реймонд выделяет 17 правил этой «философии». Я буду посвящать по одной заметке на каждое правило. Я постараюсь изложить эти концепции в максимально понятной, упрощенной и популярной форме, насколько это будет возможно.

Начнем с самого первого правила — Правила модульности. Оно звучит так: «Простые блоки связывайте друг с другом ясными и понятными интерфейсами» (Rule of Modularity: Write simple parts connected by clean interfaces).

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

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

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