Krakovetskyi-KogdaYaGovoril

71

26 апреля 2011 г

Про вред молчания

Будем исходить из того, что хороших менеджеров у нас очень мало.

Причин, как всегда, несколько:

џменеджерами становятся бывшие технари;

џменеджеры являются не техническими людьми;

џтребования бизнеса часто отличаются от идеалистической картины сотрудни-

ков;

џотсутствие нормальной школы менеджеров;

џжадность, тупость, бюрократия;

џмногие менеджеры просто мудаки (среди простых смертных мудаков тоже много, но когда они простые смертные, их одаренности особо не видно).

Что из этого следует? А то, что здравый смысл в отношениях сотрудник-

менеджер часто не действует. Возьмите книги по управлению проектами — например, «Deadline» Тома Демарко, книги Ленсиони или даже нашумевший, но тем не менее достаточно бесполезный ReWork. Книги сами по себе очень интересные и правильные, но у них одна беда — они не работают у нас.

Наблюдения:

џменеджеры очень не любят, когда им говорят, что они что-то делают не так,

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

ры) уже XXX лет на рынке, а что ты тут со своими советами». В итоге о тебе складывается мнение как об амбициозном хаме. Самое страшное то, что это,

как правило, не лечится;

џвидел, когда менеджмент (внимание!) запрещал персоналу посещать курсы,

чтобы они, набравшись опыта, не разбежались. Зарплату, естественно,

платили они небольшую;

џвидел ситуацию, когда менеджмент позволил уйти команде разработчиков вместе с тимлидом, потому что не захотели поднять зарплату на $100, но на следующий день готовы давать по полторы тысячи долларов за рекоменда-

цию;

72 Александр Краковецкий. Когда я говорил...

џкак правило, менеджеры несут какую-то невразумительную ху€ту на тему гордости за свою работу, passion, призывают к патриотическим чувствам, при этом чай на кухне может быть не всегда;

џочень редко зарплата поднимается адекватно росту профессионализма. У нас это решается просто — человек уходит на другую фирму за $200 и процесс повторяется;

џочень многие хотят получить хорошего специалиста за малые деньги, а потом кричат на всяких сайтах, что нормальных специалистов не осталось;

џочень редко (читай — практически никогда) условия до принятия на работу ==

условиям после принятия на работу.

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

— ценой $200 в новой «успешной и динамически развивающейся» компании.

73

1 февраля 2013 г.

Об идеальном коде и суровой реальности

Думаю, никто не будет спорить, что программный код должен быть чистым и «не пахнуть» (code smell), а паттерны проектирования и TDD должны стать верными спутниками любого мало-мальски грамотного разработчика на протяжении его нелегкой, но продуктивной карьеры. Все также знают, что цена ошибки в продак-

шне возрастает в десятки раз, а также то, что хорошие программисты оптимизи-

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

Было бы глупо спорить с тем, что писать хороший код — не правильно. Более того,

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

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

Далее несколько наблюдений и историй из жизни.

Аутсорсерам выгодно писать говнокод

Что уж тут скрывать, большинство успешных компаний, работающих на локаль-

ных рынках — аутсорсеры, которые, как всем известно, зарабатывают на оказа-

нии сервисных услуг внешним заказчикам. Если fixed price — ок, еще есть надеж-

да, что код будут писать грамотно, но если time & materials…

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

получил вполне резонный ответ: ты ж деньги получил и за то, что делал, и за то,

что переделывал, почему ты не доволен?

Знаю случаи, когда разработчики умышленно в системе делали баги, чтобы потом получить дополнительно заказ на поддержку. А в одной из прошлых компаний товарищ назвал свою роль в компании как «bug maker»! Он этим очень гордился, так как не давал расслабиться еще троим разработчикам и двум тестерам!

Пишете хороший код? Вас могут уволить!

Звучит совсем чудовищно, но вам не показалось. Хороший разработчик и

74 Александр Краковецкий. Когда я говорил...

сильный архитектор — всегда (?) ценный сотрудник, но в некоторых случаях

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

чески раскрашивать код в нужном порядке. Шучу? Нет.

А как же поддержка, новые разработки? Все очень просто. Очень многие компа-

нии живут за счет одного заказчика и делают все (абсолютно все), что он скажет,

т.к. его уход равен концу компании. Поэтому в такой войне все средства хороши.

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

Рефакторинг ради рефакторинга

Пожалуй, проблема всех хороших (или потенциально хороших) разработчиков.

Выбросить все и написать сначала! Добавим еще синдром «Not invented here» и

получим полный набор проблем… для начальства и заказчика. Ведь разработчи-

ки во главе с тимлидом не бизнес-проблему решают, а играют в игру под названи-

ем «Идеальный код».

Писать говнокод иногда нужно

Например, если вы пишете прототип, проверяете идею, занимаетесь Research & Development. В таких случаях идеальный код с трехуровневым ООП поверх TDD с

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

догадку, сэкономить время в будущем на исправление архитектурных или функциональных косяков.

Почему все-таки считается, что нужно писать идеальный код?

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

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

В одной из компаний, перед тем как садиться писать оценку проекта и коммер-

ческое приложение, я (в обход начальства) всегда спрашивал у заказчика:

выберите желаемый тип оценки среди трех вариантов — «дешевле, но быстрее», «работает — донт тач», «делаем как надо». В зависимости от желания клиента

Об идеальном коде и суровой реальности	75

бюджет вырастал в 2-5 раз, но зато я сразу четко понимал, как мы будем писать.

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

санного 3 года назад, хочется кого-то убить. Не дайте Астронавтам Архитектуры вас запугать!

Не нужно писать говнокод умышленно

Только по расчету!

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

регулярный код ревью. В итоге за неделю до сдачи проекта заказчики-таки раздуплились и выкатили code conventions, что ввело в ступор начальство (ну и меня тоже, т.к. сдавать продукт нужно было мне). Но за счет контроля с самого начала проекта все доработки заняли максимум день.

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

Заставьте себя написать хотя бы один проект «правильно», и потом вы просто не сможете это делать по-другому!

76

20 января 2013 г.

Несколько слов о продуктивности

Вопрос продуктивности и ответственности всегда стоит на первом месте среди требований к новым сотрудникам.

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

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

Приоритет задач

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

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

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

будете оттягивать выполнение «неприятной» для вас задачи. Она будет вас мучить все время, превращая «приятные» задачи в «не вполне приятные».

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

Главное — результат, а не процесс

В начальной школе нас учили, что глаголы могут быть совершенного и несовер-

шенного вида.

Глаголы совершенного вида указывают на завершенность действия, его резуль-

тат, конец действия или его начало. В неопределенной форме они отвечают на

Несколько слов о продуктивности 77

вопрос «что сделать?» Например: добежать, купить, зазвенеть, построить,

запеть. Обратите внимание на то, что у глаголов совершенного вида есть только две формы времени: прошедшее и будущее. Настоящее время отсутствует.

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

перечитывать, подпрыгивать. У глаголов несовершенного вида есть все три формы времени: прошедшее, настоящее и будущее.

Почему я об этом вспомнил? Наверное, потому, что все люди делятся на два типа:

на тех, для которых результат — глагол совершенного вида, и тех, для которых результат — глагол несовершенного вида.

Если вы хотите повысить свою производительность, то процесс (например,

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

Меньше отвлекаться по сторонам

В мире Twitter, Facebook и других враждебных с точки зрения продуктивности ресурсов очень сложно сконцентрироваться на задаче. Это действительно сложно, но, как говорится, нужно себя заставлять (эх, пока писал эту статью дважды отвлекся на Twitter). Нужно помнить, что любое отвлечение от текущей задачи забирает у вас от 10 до 20 минут. Если переключений контекста у вас несколько за день, то вы ничего не успеете сделать, но в то же время очень сильно устанете.

Чем интересней задача, тем больше успеваете сделать

Это действительно так. Поэтому нужно стараться делать только то, что вам действительно нравится. Но как этого добиться? — спросите вы. — Если началь-

ник приказал сделать кучу всякой бесполезной фигни, которая никому не нужна?

Это реально проблема. Всегда нужно видеть смысл в своей работе.

Если смысла нет или вы знаете, что вашу работу все равно никто не оценит,

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

78 Александр Краковецкий. Когда я говорил...

Берите пример

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

он является огромным стимулом творить и пожинать плоды своего труда.

Нужно ли пользоваться сторонними органайзерами и прочим софтом?

Ответ на этот вопрос достаточно простой: если для успешного выполнения задачи вам легче записывать все в Outlook, OneNote, Evernote или Notepad — делайте это. Если вам удобней записывать карандашиком в блокноте — используйте этот метод. Если вам удобней хранить все в голове — это тоже вариант. Самое главное,

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

Вместо вывода

Самоорганизация и умение распределять приоритеты поможет вам успешно справляться со сложными задачами и получать от этого истинное удовольствие.

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

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

79

25 декабря 2012 г.

И еще немного мыслей на тему методологий

управления проектами

Последнее время меня часто записывают в лагерь противников методологий управления проектами (чаще имея в виду agile/scrum/kanban). Это не совсем так.

Я не против методологий, я против их фанатичного применения к месту и без, а

также против просто мистической уверенности в успехе после внедрения Agile.

Мне кажется, многие не понимают, зачем вообще нужна методология.

Методология — это некий контракт (договоренность) между всеми участниками процесса. Это как язык жестов, правила дорожного движения, эсперанто или математические формулы. Отличие этих примеров от aglile/scrum/kanban в том,

что они не подразумевают различных трактовок. В случае с aglile/scrum/kanban —

каждая компания, и даже каждая команда имеет свой «канбан», который в большинстве своем вообще ничего общего с ним не имеет.

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

џОтчетность. Раз в неделю письменно, дважды в неделю (вторник и четверг) —

по Skype.

џВремя реагирования. Для обычных писем — 4 часа, для тех, которые помече-

ны как «важные» — 1 час (у многих компаниях это 15 минут).

џОбязанности. За технические вопросы отвечает Вася, за сервер — Коля, за чай на кухне — Петя.

џИ т.д.

Кпримеру, зачем писать на доске задачи, если они есть в Jira или TFS. Если вы уверены, что с этим проблем не будет — смело исключайте этот пункт из «кон-

тракта». И заметьте, таким образом вы можете комбинировать best practices

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

Задача менеджера — не написать отчет о проделанной работе или найти испол-

нителей для проекта. Управление проектом подразумевает достижение цели при отсутствии необходимых ресурсов и полной или частичной неопределенности.

Считаю, что знание методов управления рисками и основ бизнеса помогут

80 Александр Краковецкий. Когда я говорил...

среднестатической команде больше, чем внедрение agile.

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

Недавно задали вопрос: «А можно ли fixed price + agile?». Почему бы и нет. При правильном планировании. Но, опять-таки, правильное и эффективное планиро-

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

Еще одна проблема — использование agile/scrum/kanban там, где его использо-

вать не нужно. Например, в проектах с очень ограниченными сроками или R&D.

Или когда выполнение вашей задачи зависит не от вас или вашего начальника, а

от внешних факторов, на которые вы влиять не можете. Примеров можно привести множество.

В качестве выводов:

џЕсть ли смысл внедрять методологии? Однозначно.

џЕсть ли смысл использовать agile везде? Нет.

џЕсть ли смысл на всех форумах и сайтах, где есть слово «методология» писать

«agile всех спасет, а если нет, у вас руки из жопы растут»? Воля ваша, но со стороны вы выглядите, как минимум, глупо.

џНужно ли читать книги о методологиях и ходить на agile тусовки? Однозначно,

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

џНу и, наконец, какая методология лучше? Лучшей методологии нет. Лучшая методология — та, которая подходит вам, вашей команде и заказчику в конкретный момент и в конкретном месте и проекте.