Предыдущая статья была достаточно популярна. Я обещал продолжить и держу слово. Делюсь своим личным мнением и не претендую на истину.
В этой части пойдет речь про работу с программистами.
1. Вместо костылей нужен фундамент. Люди, а не методологии
Из опыта внедрений различных методологий Agile сделал следующие выводы
1. Вполне понятным кажущимся решением многим кажется использование типовых советов. Вера в серебряную пулю, джинна из бутылки свойственно большинству людей, менеджеры проектов — не исключение.
2. В последние годы популярным распиаренным решением стали всевозможные гибкие методики, про которые не писал только ленивый. Об этом качестве людей подробно будет ниже.
3. Однако, на практике внедрение чаще всего вместо ожидаемого порядка из хаоса не приводит к автоматическому повышению управляемости процессом разработки. Как правило, благодаря тому, что тупо берется некий каркас, но при этом не учитываются глубинные причины простоев. Некоторые успехи, конечно, есть — как есть и у раздельного питания, к примеру. Но в случае с раздельным питанием люди просто начинают следить за тем, что едят, и уже это часто помогает вкупе с плацебо. Так и метолодолии могут дать эффект, если раньше просто был просто хаос.
4. Как ответ разработчиков на все это, появились знаменитый английский манифест «Programming, Motherfucker! Do you speak it?» и его русский вариант.
5. В конечном счете, вода камень точит. Не буду утверждать, что методологиями в стиле «потратим час на [censored] болтовню» программистов достали, но какая-то доля влияния здесь есть. Наиболее рутинные куски в разработке стандартизовали и автоматизировали — и все чаще стали появляться прекрасные статьи от Яндекса, Badoo и так далее, как выстроен процесс разработки. Где большое внимание уделено техническим инструментам, которые реально роляют на процесс разработки, в отличие от бесконечных плясок с бубном.
Хочу отметить, что с программистами, которые умны и хотят работать, достаточно легко взаимодействовать. Вы объясняете человеку, зачем нужен функционал, и обсуждаете user stories. Какие-то архитектурные моменты. И дальше человек реализует то, что нужно, точно и красиво.
При этом время, потраченное на поиск таких программистов, окупается сторицей. Нежели чем вы просто наберете рэндомных людей и будете пытаться с их помощью построить некую «разработку», применяя «методологии». Если будут хорошие люди — инструменты для себя они напишут, или возьмут готовые.
Кадры решают все, об этом сто раз писали, но грабли до сих пор свеженькие и отполированные новыми лбами.
2. Управление требованиями и входными данными как эффективное средство упрощения задач
Хочется сразу отметить, что я не верю в теоретические знания. Можно прочитать сто книжек и сдать на PMI, MBA и множество других слов, но заваливать все проекты. А можно и делать проекты, как пирожки, не владея ценными «знаниями».
Речь пойдет о навыке, которые развивается в процессе практики. Хочу привести лишь пару примеров, чтобы было понятно, в каком направлении мыслить и какой эффект это может дать.
Кейс 1. Делается рассылка e-mail писем, ссылка в которых ведет на лэндинг. Встает задача у молодого менеджера проектов, ограничить от спама форму на лэндинге.
Берется пример у другой рабочей группы, как сделать такую защиту на 8+ часов.
И тут приходит более опытный человек, и предлагает внимательно изучить начальные условия. Лэндинг предназначен только для открытия из почтовых писем.
Следовательно, в первой версии достаточно в ссылках из писем ставить некий ключ в URL, который будет вызывать показ формы на лэндинге. А при прямом заходе форму не показывать.
Придумать — одна минута, делать — 15 минут. Против 8+ часов. Без комментариев.
Кейс 2. Обращается ко мне менеджер проектов. Нужно, мол провести опрос на проекте. Был какой-то движок опросов, можно ли его прикрутить, или писать свой.
Последовательно задаются вопросы
— Сколько раз нужно проводить опрос? Ответ: один раз
— Будут ли меняться поля: Ответ: нет, не будут.
— Сколько участвует в опросе пользователей. Ответ: десяток.
Через минуту выдаю решение — сделать форму на Гугл Докс, и поставить на проекте ссылку. Реализация — минуты, против дней на прикрутку движка опросов, отладку, вынос на релиз и так далее.
Сюда же относится и занос контента статикой (HTML), если он не меняется чаще раза в месяц, вместо создания движка и WYSIWYG, и много других вещей.
Овладев уточнением исходных условием и держа мысль в голове «как это можно сделать проще и быстрее», вы можете значительно ускорить разработку. И научить этому своих программистов.
3. Раскрытие личностного потенциала вместо шаблонного общения
Программисты, как и любые другие творческие личности, уникальны. Ведь не стали бы вы общаться с Азимовым в роли издателя так, как общались бы с Толстым. А с Пушкиным тоже бы вели свой диалог.
У каждой яркой личности есть свои плюсы и минусы. Нередко при этом программистов, как сложных и непонятных для нетехнарей, пытаются классифицировать определенным образом. И применять стандартные методики, фразы, вопросы.
Начинается все с шаблонных вопросов на собеседовании про «кем вы видите себя в компании через 5 лет», и может продолжаться весь срок работы человека в компании.
Это возможно, но для работы с талантами, мне кажется, не очень подходит.
Например, у меня работает талантливый программист, в прошлом дизайнер и верстальщик. Достаточно уникальный опыт, и поэтому с ним в процессе общения и постановки задач можно не беспокоиться, что он сделает некрасиво. И задачи я подбираю такие, которые наиболее точно позволят ему раскрыться. Мне кажется, это его мотивирует — и неспроста он уже развивает целые проекты в моем отделе.
А есть программист — спец по ООП. Он очень надежный, и всегда все проверяет. Но любит усложнять. И с ним можно в общении не беспокоиться, что в релиз попадет неработающий функционал.
В итоге, когда поступает проект, можно делить его на блоки, которые наилучшим образом соотносятся со способностями команды, что очевидным образом сказывается на эффективности и производительности.
Каждый программист имеет свои способности, свое прошлое, и индивидуальный подход, по моему мнение — то, что может повысить вашу продуктивность работы с командой в разы. Гораздо лучше, чем всех согнать в один опен-спейс, чтобы люди чаще болели и мешали друг другу шумом, несмотря на то, что это рекомендуют разные «дипломированные ребята». Демарко писал об этом 20 лет назад и до сих пор актуален.
4. Не идите за всеми — это нередко кончается провалом
Степан Демура, неоднозначный, но яркий трейдер как-то сказал, что если вы будете стоять на рынке так же, как и толпа, то вы обязательно проиграете.
Как ни странно, это правило работает и в управлении проектами. Чем больше будет вокруг суеты, в топиках — стадного чувства, тем меньше советую идти на поводу у инстинктов.
Мы когда-то, как и все, кинулись делать городской портал. И были побиты конкурентами. Хотя, казалось бы, все делают, и у всех должно получиться.
Увы, есть простая аналогия, которая говорит, что ресурсов почти всегда меньше, чем их потенциальных потребителей, и имеет место конкуренция.
Вот стоит палатка с молоком, и в день ходит 100 человек. Палатка успешна, и появляются конкуренты 2,3,4,...N. А как ходило 100 человек, так и ходит. Но прибыль каждой уменьшается с появлением новых, и в конечном итоге разоряются все (один из вариантов сценария).
Вот и так происходит с новыми нишами в бизнесе (вспомните те же купонаторы).
Есть и другой пример, где данная рекомендация работает чуть иначе.
Вчера все сидят на NoSQL, сегодня пилят на jQuery, завтра SVG+HTML5, послезавтра 3d для FaceculusRift.
В итоге, следуя за модой на технологии, вы получаете проект-зоопарк, где дружить технологии все труднее и труднее. Примеров много.
В противоположность один известный сайт бронирования отелей, работающий на [censored] мамонтов Perl. Я на Perl не писал уже лет 10, и все жду легендарного Перла 6. Офигенный был язык (и остается). Насколько я знаю, ежики колются, плюются, но продолжают жрать кактус. И проект растет и развивается, не страдая от резкий падений «а потом мы переписали все на Джаве (подставьте ваш язык) и купили еще 1000 серверов, чтобы не падало каждый час».
Такие неочевидные вещи, которые начинаются с и управления своим выбором, казалось бы, мало относятся к разработке. Но с мысли начинается одержимость, а где одержимость — там фанатизм. Который и приводит к стратегическим фейлам.
Вот говорят, на дизайне исправить ошибку в 1000 раз дешевле, чем на продакшене. А в — в infinity раз. Только мало кто задумывается об этом, судя по неудачным стартапам повсюду.
5. Научитесь программировать
Вот говорят, что рыбак рыбака узнает издалека. Даже если вы ничего не прочитали и просто прокрутили вниз, вы уже получите пользу.
Если вы научитесь программировать, то обойдете сотни тысяч молодых парней и девушек, кто мечтает о высокой зарплате в IT, но хотят только управлять.
Ибо своих любят и признают в любой среде, а если руководитель программиста технически подкован, то это дает +1000 (ИМХО) к скиллу уважения.
Но, по исследованиям, к авторитетам лучше прислушиваются.
Приложу хорошую ссылку (еще еще одна) и ролик выдающихся и известных людей, почему вам стоит научиться программировать.
В комментариях предлагаю поделиться вашими находками из опыта, какими-то кейсами, которые считаете интересными.
Автор: Cord
