Comments 30
Чуть слезу не пустил. Прям каждая буква по самому больному. Может в стартапах как-то поадекватнее, но я всю жизнь по корпорациям и «политика» здесь самое невыносимое. А еще для управления внутрикорпоративными сложностями используются 100500+ внутренних корпоративных ресурсов, вносящих неверноятную сложность даже в самые простые действия. Ох.
Может в стартапах как-то поадекватнее
«Так» абсолютно везде, где в какой-то момент времени было решено, что теперь нужно сосредоточиться на управлении.
Неважно, стартап это или нет. Отчаянными попытками попланировать и поуправлять (в ущерб полезной работе) можно запороть и команду из трех человек.
Эта проблема обычно возникает тогда, когда кто-то сумеет убедить руководство, что где-то в недрах организации существует значимый запас прочности, для регулярного использования которого нужно всего лишь оптимизировать систему управления (в том числе за счёт личной эффективности и мотивации линейных сотрудников). Редко руководство спрашивает этого "кого-то" о происхождении исходных утверждений и о том, чем обернется это все.
Из моего личного опыта, в стартапах меньше политики, но зато намного больше так называемых «отношений». На хабре регулярно появляются статьи про «типичные ошибки стартапов», в которых большими буквами пишут: «не делайте стартап с друзьями». Так что если выбирать между корпорациями и стартапами, то еще неизвестно, где хуже.
Использовать гениальных проектировщиков, умеющих отсеять лишние требования и организовать оставшиеся в «собирающуюся» систему.«Эффективные менеджеры» не просто не понимают этого — они этого не умеют в принципе! Понимание того что не все работники — ресурс/биомасса очень противоречит как их ЧСВ так и очень распространенным сейчас в западном обществе левацким взглядам про равенство-братство.
Вот теперь мы можем понять, почему не работает способ «просто добавьте денег».Очень даже работает, только иногда надо просто сократить-заменить команду на пару-тройку тех самых гениальных и платить им эти «добавленные деньги».
Если мы с 1975 года знаем, что сложность проектов растет, к примеру, квадратично, — что мешает точно так же квадратично увеличивать бюджет и команду? Почему все новые поколения менеджеров продолжают вести проекты с прогнозируемой успешностью в 30%, когда можно просто добавить денег?
Да, многие недооценивают и не понимают, насколько быстро растет квадратичная функция. Да, даже x^(3/2). Представьте, что вы потратили на написание программы 1000 у.е. за 1 год и вы заработали 10 000. У вас поступили заказы (в 10 раз больше), вы уже тратите 100 000 в год (100 раз) на написание новых функций, прибыль выросла в 10 * log 10. Продолжая рост в таком темпе, уже в следующем году расходы составят не 10 млн, а 232 млн!
1 000 ^ 1.67 = 100 000
100 000 ^ 1.67 = 240 000 000
И это еще мы не упоминаем о том, что в модели COCOMO оценка стоимости программного обеспечения является экспоненциальной (что гарантированно хуже любого полинома!). К счастью, с относительно небольшим коэффициентом в показателе экспоненты. Но общий принцип остается тем же: если можно разработать три продукта по 100k строк вместо монолита за 300k строк — это немедленно следует ровно так и делать. А вот уж как обеспечить возможность деления продукта, чтобы команды могли разрабатывать, тестировать и деплоить свои компоненты независимо — это и есть главная головная боль менеджера проектов и архитектора. Микросервисы, ООП, interface-based programming, плагины, embedded scripting и прочее в помощь…
В обсуждении на фейсбуке мне упомянули микросервисы (именно «три проекта по 100К строк вместо одного на 300К») и их ближайшую перспективу — возникновение проблем с проектированием их взаимодействия.
«От проблем нельзя избавиться, но можно время от времени менять одни на другие» ©.
Сам по себе микросервис не решает проблему сложности. Потому что — ну в самом деле, что такое микросервис: ну вытащили мы некий код в отдельное адресное пространство. Ну перестали передавать этому куску кода параметры через стек и регистры, а стали сериализовать и толкать через REST API, например. Тут сложность скорее увеличилась, а не наоборот.
Но если сервис выделен правильно, и архитектура системы изначально такая, что это (правильное!) выделение возможно — тогда вдруг происходит чудо: пользователи сервиса видят красивое и прозрачное API, и сложность выделенного сервиса перестает влиять на сложность остального приложения.
Приведу пример: при взаимодействии с промышленным оборудованием, оно обычно подключается через последовательный порт. И там все более-менее просто. Но в какой-то момент мы начинаем подключать его через TCP/IP — и (почему-то!) не замечаем, что теперь у нас задействовался TCP, congestion control, весь стек сетевых драйверов, NAT и прочие прелести ядра Linux. Поскольку это все там изолировано, и оттуда торчит только fd (file descriptor), единый как для сокета, так и для последовательного порта — сложность нашего куска системы практически не изменилась.
Мне кажется, что предупреждения в фейсбуке связаны с тем, что иногда встречается без(д)умное деление системы на микросервисы. При этом они не оказываются логически законченными и изолированными — и мы получаем тот же кошмар масштаба, что и в монолитном приложении, но приправленный еще и чисто специфическими возможными проблемами в контейнеризации, service-discovery, мониторинге и т.п.
Сам по себе микросервис не решает проблему сложности. Потому что — ну в самом деле, что такое микросервис: ну вытащили мы некий код в отдельное адресное пространство. Ну перестали передавать этому куску кода параметры через стек и регистры, а стали сериализовать и толкать через REST API, например. Тут сложность скорее увеличилась, а не наоборот.
Но если сервис выделен правильно, и архитектура системы изначально такая, что это (правильное!) выделение возможно — тогда вдруг происходит чудо: пользователи сервиса видят красивое и прозрачное API, и сложность выделенного сервиса перестает влиять на сложность остального приложения.
Приведу пример: при взаимодействии с промышленным оборудованием, оно обычно подключается через последовательный порт. И там все более-менее просто. Но в какой-то момент мы начинаем подключать его через TCP/IP — и (почему-то!) не замечаем, что теперь у нас задействовался TCP, congestion control, весь стек сетевых драйверов, NAT и прочие прелести ядра Linux. Поскольку это все там изолировано, и оттуда торчит только fd (file descriptor), единый как для сокета, так и для последовательного порта — сложность нашего куска системы практически не изменилась.
Мне кажется, что предупреждения в фейсбуке связаны с тем, что иногда встречается без(д)умное деление системы на микросервисы. При этом они не оказываются логически законченными и изолированными — и мы получаем тот же кошмар масштаба, что и в монолитном приложении, но приправленный еще и чисто специфическими возможными проблемами в контейнеризации, service-discovery, мониторинге и т.п.
Вот да, реальное решение проблемы — это архитектурно правильное выделение сервиса. А массовое решение — это «все переводим на микросервисы». В результате лет через пять (а может и уже) от них начнут перебегать к какой-нибудь новой модной технологии.
мы начинаем подключать его через TCP/IP — и (почему-то!) не замечаем
Не замечаем, пока не протечёт абстракция, а после того начинается тюнинг параметров, отключение алгоритма Нагла, переписывание с TCP на UDP с собственным контролем перегрузки и противодействия потерь.
А с распределёнными системами ещё и возникает скрытое состояние в виде сообщений-в-транзите, которое человеку осознать довольно тяжело.
Мы тут дискутируем с коллегой на эту тему периодически. На мой взгляд проблема с микросервисами в том, что по сути предполагается, что они реализованы плюс-минус идеально и никому не надо лезть внутрь для поддержки и развития. А если уже понадобилось соответствовать, то выбросили старый и написали другой. Проблема в наших спорах одна — коллега он такой чистый теоретический программист уровня спикера митапов, а я прикладной математик — 3Dшник. Для него микросервис это блок кода, а для меня в нём возможно запрятан сложный вычислительный алгоритм с прибамбасами. Который реализует какую-то бизнес-логику и требования к ней, в отличие от протоколов TCP/IP могут измениться из разряда «а теперь котики умеют летать».
В таком варианте микросервис, на мой взгляд, оказывается адским адом поскольку, во первых, предполагается, что внутри «ящика» разработчик может делать что угодно, главное чтобы интерфейс был удобным. А во вторых… Во вторых по сути поддержка этого дела ничем не отличается от поддержки блока кода кроме усложнённых взаимодействий с внешними элементами системы.
А переписать какой-нибудь тесселятор для извращённых геометрий, на который потратили полтора года с нуля — утопия, которую никакому менеджменту не продашь.
Так что, как мне кажется, в мире систем с долгим жизненным циклом и сложными компонентами это чревато наоборот деградацией в возможности поддержки и развития кода.
В таком варианте микросервис, на мой взгляд, оказывается адским адом поскольку, во первых, предполагается, что внутри «ящика» разработчик может делать что угодно, главное чтобы интерфейс был удобным. А во вторых… Во вторых по сути поддержка этого дела ничем не отличается от поддержки блока кода кроме усложнённых взаимодействий с внешними элементами системы.
А переписать какой-нибудь тесселятор для извращённых геометрий, на который потратили полтора года с нуля — утопия, которую никакому менеджменту не продашь.
Так что, как мне кажется, в мире систем с долгим жизненным циклом и сложными компонентами это чревато наоборот деградацией в возможности поддержки и развития кода.
Я не из ИТ. Занимаюсь инженерными и строительными проектами. Но всё тоже, всё также. «Политика» очень быстро начинает съедать слишком много времени. Большие инженерные команды приводят к отвратительным интерфейсам между дисциплинами. А человеко-месяц опытного инженера не равен даже человеко-году стажёра. Работу опытного инженера не выполнет отдел новичков.
Жаль, что в инженерии и строительстве метод Scrum неприменим.
Жаль, что в инженерии и строительстве метод Scrum неприменим.
У Сазерленда упомянут «сосед», который сделал себе ремонт дома по Scrum. Так что возможно скрам в строительстве и применим. Другое дело, что никакой скрам не сделает из новичка профессионала — если никто в команде не знает, как правильно сделать Х, Х будет сделано неправильно.
Только что прочитал про ремонт дома «по Scrum». Думаю, я плохо представлял себе методику Scrum. Если всё так, как описано в книге «Scrum» Джефф Сазерленд, то это так, как начинают работать при авралах на строительстве, когда срок окончания не за горами, а сделано мало. Не всегда так, конечно. Но это и понятно. Когда строится большой промышленный объект где-то в Приморском крае и в ходе очередного утреннего обсуждения стало ясно, что нужно купить ещё кабеля, фермы перекрытий нужно укреплять и что-то ещё, не важно что, легче от этого не станет никому. Срок поставки кабеля будет около двух месяцев или он станет золотым по цене, фермы изготавливают пол-года, да и другие проблемы решаются за недели.
Я подозреваю, что проблема была в том, что методологии управления инженерными и строительными проектами, когда нужно предусмотреть необходимые ресурсы за пол-года, год, но проект по своей сути не нов, а отличается от ранее реализованных какими-то деталями, масштабом или чем-то ещё стали применять в программировании. Где всё не так.
Я подозреваю, что проблема была в том, что методологии управления инженерными и строительными проектами, когда нужно предусмотреть необходимые ресурсы за пол-года, год, но проект по своей сути не нов, а отличается от ранее реализованных какими-то деталями, масштабом или чем-то ещё стали применять в программировании. Где всё не так.
Пожалуй, Вы правы, первоначально методологии создания больших программных систем были позаимствованы из «хардварных» проектов, с их обязательными задержками по поставкам комплектующих и (взамен) работоспособностью комплектующих. В программировании же «сборка» проекта из готовых модулей стала работать только в последние десятилетия (когда появилось достаточное количество таких модулей-библиотек). А до этого приходилось фактически каждый раз создавать кабеля, балки и фермы заново, с непредсказуемой работоспособностью. В результате методология, отлично работавшая например в строительстве, оказалась не помощником, а тормозом.
Очень даже применим. Смотрите опыт аэропорта Анапы. Смотрите Евгения Пикулева (http://featmanagement.ru/) из Базэл Аэро. Руководитель проектов по строительству нового/ реконструкции старого аэровокзалов аэропорта Анапы.
«Я смогу назвать срок, только когда увижу, насколько эффективно будет действовать команда»
Старик и путник (длинная версия)
По дороге в безлюдной местности шёл путник. А у дороги под деревом в глубокой медитации сидел, закрывши глаза, старик. Путник подошёл к старику и, не обращая внимания на его медитацию, громко поприветствовав его, спросил:
— Почтенный, долго ли мне ещё идти до ближайшего города?
Старик открыл глаза, и, как будто не выходя из своей медитации, махнул рукой в ту сторону, куда шёл путник и сказал:
— А ты иди.
Путник понял, что с ним не хотят разговаривать. Обидевшись, он отвернулся от старика и быстро зашагал дальше по дороге. Но, пройдя лишь с десяток шагов, путник услышал позади голос старика:
— Если так будешь идти, дойдёшь до захода солнца
— Почтенный, долго ли мне ещё идти до ближайшего города?
Старик открыл глаза, и, как будто не выходя из своей медитации, махнул рукой в ту сторону, куда шёл путник и сказал:
— А ты иди.
Путник понял, что с ним не хотят разговаривать. Обидевшись, он отвернулся от старика и быстро зашагал дальше по дороге. Но, пройдя лишь с десяток шагов, путник услышал позади голос старика:
— Если так будешь идти, дойдёшь до захода солнца
Почему проекты так сложно закончить в срок и почему Scrum в этом не поможет? На практике по классике проектного управления при использовании проектного треугольника ограничений (сроки, деньги, функциональность) обычно гонятся за необходимостью обеспечить полную функциональность, отраженную в ТЗ, конечно же по ходу проекта появляются новые требования или существующие проходят уточнения. Отсюда плывут деньги и/или сроки.
Что предлагает Scrum? По мнению одного из авторов agile манифеста необходимо фиксировать не функционал, а сроки и деньги. И вот тут и получается, чтобы сделать проект вовремя и в бюджете приходится жертвовать функционалом. Так что опять же на практике бизнес на такое обычно не идёт. Топам нужно понимать, когда деньги вернутся от проекта. Scrum молчит на этот счет.
По проблемам: сложность продукта?
А разбивать на более мелкие части? Подпроекты? Фичи? В соответствии с ними дробить одну большую команду на несколько мелких? Да и планировать мелкие фичи (подпроекты) удобнее. И не надо детально плнировать, достаточно roadmap сделать.
Идем далее. Можете назвать сроки после понимания эффективности команды? И Топы вам такое позволяют? Скажите, где это — мы идем к вам. Обычно же сроки всегда! ограничены. Может не называются топами, но в голове у них они есть. Так что…
А все проблемы в проектах из-за людей, из-за их неумения коммуницировать, из-за низкой коммуникативной компетенции руководителя проекта.
Что предлагает Scrum? По мнению одного из авторов agile манифеста необходимо фиксировать не функционал, а сроки и деньги. И вот тут и получается, чтобы сделать проект вовремя и в бюджете приходится жертвовать функционалом. Так что опять же на практике бизнес на такое обычно не идёт. Топам нужно понимать, когда деньги вернутся от проекта. Scrum молчит на этот счет.
По проблемам: сложность продукта?
А разбивать на более мелкие части? Подпроекты? Фичи? В соответствии с ними дробить одну большую команду на несколько мелких? Да и планировать мелкие фичи (подпроекты) удобнее. И не надо детально плнировать, достаточно roadmap сделать.
Идем далее. Можете назвать сроки после понимания эффективности команды? И Топы вам такое позволяют? Скажите, где это — мы идем к вам. Обычно же сроки всегда! ограничены. Может не называются топами, но в голове у них они есть. Так что…
А все проблемы в проектах из-за людей, из-за их неумения коммуницировать, из-за низкой коммуникативной компетенции руководителя проекта.
Что все проблемы от людей — это Вы самую суть ухватили! :)
По мнению одного из авторов agile манифеста необходимо фиксировать не функционал, а сроки и деньги.
Што? Я конечно не почитатель аджайла, но о таком слышу впервые (от вас). Скрам и аджайл вообще никаким боком к срокам, там измеряется (и контролируется) скорость разработки.
А разбивать на более мелкие части? Подпроекты? Фичи? В соответствии с ними дробить одну большую команду на несколько мелких? Да и планировать мелкие фичи (подпроекты) удобнее. И не надо детально плнировать, достаточно roadmap сделать.
А всё вместе оно у вас заведется так сразу, как вы ножкой топнете?
Разбиение уменьшает сложность, но только частично. Оставшаяся часть сложности просто перемещается на уровень выше (уровень взаимодействия ваших частей, подпроектов, фич, и так далее).
Обычно же сроки всегда! ограничены.
Так это у вас в аджайле или всё же «обычно <кем-то сверху> ограничены»? Вы уж определитесь.
Ари ван Беннекум — сходите на его тренинг "agile в бизнесе" — полезно будет. А то по вам получается, что agile в компании сам по себе, и вы там пилите и пилите продукт, а топы вам деньги только подваливают и подваливают. Мечта просто. Странный у вас какой то бизнес, не, ну если это очередное сайтостроительство, то наверное. А в энтерпрайзе люди чаще всего деньги считают. И agile там есть, только он там связан с бизнесом, а не сам по себе.
А то по вам получается, что agile в компании сам по себе, и вы там пилите и пилите продукт, а топы вам деньги только подваливают и подваливают. Мечта просто.
Может для вас это сюрприз, но де-факто вся сложная деятельность (и разработка тоже) именно так и идёт. В обсуждаемой статье даже подробно расписано, почему именно так.
Вопрос.
Проекты сложны из-за инструментов, которые используются или из-за амбиций, которые в них закладываются?
У меня нет уверенности в том, что в большинстве случаев, имея продвинутую платформу, дружелюбный персонал, всякие плюшки для работы и расширенные сроки, проект, поднимающийся с нуля, сможет обойтись без передвижений по графику и дополнительных вливаний. Если это проект не включающий в себя уже проторенные дорожки или знакомые инструменты (желательно старых версий) только на одно переобучение и понимание уйдёт первая половина срока.
Иногда это походит на новую операционную секцию в которую завезли лапароскоп, но либо наняли, либо уже на местах есть хирурги которые и резать в принципе умеют и хороший послужной список у них, только вот с этой машинкой не работали еще ни разу.
По мне, если человеческий фактор играет слишком большую роль в проекте — его нужно всячески урезать. То что ты не сможешь зарезать — умаслить и поставить защиту от дурака.
Не нужно забывать, не всё программирование — художественная часть. Нет, ни в коем случае. Тот кто создаёт проект может мыслить творчески, он отвечает и за основную идею и за её продвижение. Работа с начальством и инвесторами это тоже часть твоих обязанностей. Работа с людьми это уже немалая часть обязанностей, которая поможет как и выбить нужный бюджет, так и согласовать сроки. Всё что ниже, вплоть до эникейщика — работники занимающиеся строительством, люки которые забивают гвозди, люди которые ставят окна, заливают фундамент и так далее. Обратная связь конечно же должна иметь место, но при этом не нужно забывать что да, тебе придётся делать сухие телодвижения и думать в основном как робот, чтобы продвинуться дальше.
Не обузданная творческая деятельность приведёт к наращиванию ненужных ветвей разработки, которые либо полноценно не будут работать, либо заставят проект повернуться в совершенно другую сторону.
Цифровым проектам необходимо эволюционировать хотя бы в плане инструментария. Потихоньку внедрять инструменты для второго и третьего уровней программирования, когда работник не сталкивается с кодом напрямую, а лишь налаживает логическую цепочку между модулями, в то время как модули поддерживаются классическими кадрами и ими же переписываются, причём всё это в опенсорсе.
Проекты сложны из-за инструментов, которые используются или из-за амбиций, которые в них закладываются?
У меня нет уверенности в том, что в большинстве случаев, имея продвинутую платформу, дружелюбный персонал, всякие плюшки для работы и расширенные сроки, проект, поднимающийся с нуля, сможет обойтись без передвижений по графику и дополнительных вливаний. Если это проект не включающий в себя уже проторенные дорожки или знакомые инструменты (желательно старых версий) только на одно переобучение и понимание уйдёт первая половина срока.
Иногда это походит на новую операционную секцию в которую завезли лапароскоп, но либо наняли, либо уже на местах есть хирурги которые и резать в принципе умеют и хороший послужной список у них, только вот с этой машинкой не работали еще ни разу.
По мне, если человеческий фактор играет слишком большую роль в проекте — его нужно всячески урезать. То что ты не сможешь зарезать — умаслить и поставить защиту от дурака.
Не нужно забывать, не всё программирование — художественная часть. Нет, ни в коем случае. Тот кто создаёт проект может мыслить творчески, он отвечает и за основную идею и за её продвижение. Работа с начальством и инвесторами это тоже часть твоих обязанностей. Работа с людьми это уже немалая часть обязанностей, которая поможет как и выбить нужный бюджет, так и согласовать сроки. Всё что ниже, вплоть до эникейщика — работники занимающиеся строительством, люки которые забивают гвозди, люди которые ставят окна, заливают фундамент и так далее. Обратная связь конечно же должна иметь место, но при этом не нужно забывать что да, тебе придётся делать сухие телодвижения и думать в основном как робот, чтобы продвинуться дальше.
Не обузданная творческая деятельность приведёт к наращиванию ненужных ветвей разработки, которые либо полноценно не будут работать, либо заставят проект повернуться в совершенно другую сторону.
Цифровым проектам необходимо эволюционировать хотя бы в плане инструментария. Потихоньку внедрять инструменты для второго и третьего уровней программирования, когда работник не сталкивается с кодом напрямую, а лишь налаживает логическую цепочку между модулями, в то время как модули поддерживаются классическими кадрами и ими же переписываются, причём всё это в опенсорсе.
Если еще раз посмотреть на графики «крестов», то можно увидеть, что проекты бывают не только сложными, но и простыми. В левых частях графиков — все хорошо. Проблемы начинаются примерно с середины.
А сложными проекты могут оказаться не только из-за сложности продукта, команды или планирования, но и из-за любой другой сложности (например, пресловутого «рынка», сделали классный продукт — а он «не пошел»). И основная мысль статьи — что нужно уметь видеть эти сложности, а не просто следовать некоему фреймворку или хотелкам заказчиков.
Кстати, «необузданная творческая деятельность» точно так же способна взвинтить сложность продукта до небес и исключить какие-либо шансы на то, что он когда-то заработает :)
А сложными проекты могут оказаться не только из-за сложности продукта, команды или планирования, но и из-за любой другой сложности (например, пресловутого «рынка», сделали классный продукт — а он «не пошел»). И основная мысль статьи — что нужно уметь видеть эти сложности, а не просто следовать некоему фреймворку или хотелкам заказчиков.
Кстати, «необузданная творческая деятельность» точно так же способна взвинтить сложность продукта до небес и исключить какие-либо шансы на то, что он когда-то заработает :)
Да, уметь преодолеть эти сложности, не потеряв в доле проекта или в нервных клетках людей, это и есть быть хорошим работником или управленцем. Но с этим только опыт поможет. Хотя, некая стандартизация всё же помогает. По сути, ты всегда приходишь к определенным сеткам управления, просто модернизируешь их под свои нужды.
Еще добавлю в режиме «managerial hat on»: SCRUM/AGILE — не самая удобная или комфортная методология для менеджера. Потому что где-то там во внешнем мире существует понятие сделки. То есть другие люди хотят от вас понимания: какой результат будет достигнут, в какие сроки, и за какие ресурсы?
Хотя бы просто для того, чтобы оценить альтернативы.
И вы, как менеджер, обязаны эту оценку дать, и за нее (плюс-минус) нести ответственность. А протранслировать эту ответственность на разработчиков (пусть подпишутся под графиком, да и дело с концом!) вы в рамках Agile не можете. И это неприятно. Но два момента:
Во-первых (и об этом неоднократно упомянуто в статье) — в условиях неопределенности жесткие методологии работают еще хуже. Упрощается только процесс поиска виновных — но легче от этого обычно не становится. И поверьте: если проект израсходовал первоначальный бюджет, но выдал в продакшн 80% функционала (и его не закрыли на итерациях раньше) — значит уже есть реальная выгода от внедрения и можно договориться о выделении дополнительных ресурсов. Такие переговоры — малоприятное занятие, но жить можно. Когда тебя ведут расстреливать за расходование бюджета проекта БЕЗ осязаемых результатов — это куда более печальная история. :-)
Во-вторых — повышенная зарплата менеджерам платится не просто так. Если ответственность, прилагаемая к менеджерской шапке не нравится — правильнее от должности отказаться и развивать карьеру в другом направлении. Все люди разные, и кому-то это может подойти больше, чем условному вам.
Хотя бы просто для того, чтобы оценить альтернативы.
И вы, как менеджер, обязаны эту оценку дать, и за нее (плюс-минус) нести ответственность. А протранслировать эту ответственность на разработчиков (пусть подпишутся под графиком, да и дело с концом!) вы в рамках Agile не можете. И это неприятно. Но два момента:
Во-первых (и об этом неоднократно упомянуто в статье) — в условиях неопределенности жесткие методологии работают еще хуже. Упрощается только процесс поиска виновных — но легче от этого обычно не становится. И поверьте: если проект израсходовал первоначальный бюджет, но выдал в продакшн 80% функционала (и его не закрыли на итерациях раньше) — значит уже есть реальная выгода от внедрения и можно договориться о выделении дополнительных ресурсов. Такие переговоры — малоприятное занятие, но жить можно. Когда тебя ведут расстреливать за расходование бюджета проекта БЕЗ осязаемых результатов — это куда более печальная история. :-)
Во-вторых — повышенная зарплата менеджерам платится не просто так. Если ответственность, прилагаемая к менеджерской шапке не нравится — правильнее от должности отказаться и развивать карьеру в другом направлении. Все люди разные, и кому-то это может подойти больше, чем условному вам.
По моему, проекты это прежде всего про людей и только во вторую очередь про технические сложности.
Если проект становится не успешным, это не потому что команда встретилась с технической сложностью. Но различное понимание ключевыми стэйкхоледами функциональности будущей системы вполне может к этому привести. Перфекционизм и стремление разработчиков сделать все по правилам может значительно отложить запуск. Карьерные амбиции вновь назначенного менеджера проекта могут привести к тому что ничего не будет готово даже за втрое больший срок.
Стремление молодого и талантливого архитектора опробовать новые модные технологии может привести к неожиданно резкому увеличению бюджета вместо ожидаемой экономии.
Тихий саботаж со стороны сотрудников которых планируется уволить после запуска системы, и которых кто-то додумался включить в проектную команду, может привести к тому система вообще никогда не будет запущена.
В целом практики аджайл преследуют ровно две цели обьединить участников проекта общей целью и жестко контролировать расходы (на выходе из каждой итерации всегда есть шанс бросить вкладывать деньги в гнилое дело).
Если проект становится не успешным, это не потому что команда встретилась с технической сложностью. Но различное понимание ключевыми стэйкхоледами функциональности будущей системы вполне может к этому привести. Перфекционизм и стремление разработчиков сделать все по правилам может значительно отложить запуск. Карьерные амбиции вновь назначенного менеджера проекта могут привести к тому что ничего не будет готово даже за втрое больший срок.
Стремление молодого и талантливого архитектора опробовать новые модные технологии может привести к неожиданно резкому увеличению бюджета вместо ожидаемой экономии.
Тихий саботаж со стороны сотрудников которых планируется уволить после запуска системы, и которых кто-то додумался включить в проектную команду, может привести к тому система вообще никогда не будет запущена.
В целом практики аджайл преследуют ровно две цели обьединить участников проекта общей целью и жестко контролировать расходы (на выходе из каждой итерации всегда есть шанс бросить вкладывать деньги в гнилое дело).
По моему, проекты это прежде всего про людей и только во вторую очередь про технические сложности.
Смотря какие у вас проекты. Сайты магазинов товаров клепать — да, невелика техническая сложность, и грабли уже все собраны до вас.
Но не все клепают сайты магазинов. Многие делают то, аналогов чего в мире нет, а очень многие — то, что имеет аналоги, но довольно отдалённые и плохо применимые.
Sign up to leave a comment.
Аллюр три креста, или Почему проекты так трудно закончить в срок