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