Комментарии 23
уберите везде упоминание про ИТ и всё написанное будет работать в любой области. Проблема этой статьи в том что читающий руководитель-самодур априори не способен понять что тут написано, ну или прекрасно понимает, но не думает что это связано с ним.
Большинство, став руководителями, перестают вообще что-то читать. Во-первых, раз он стал руководителем, то лучше всё знает, чем какие-то теоретики. Далее, когда ЧСВ улетает в стадию насыщения у неподготовленных руководителей, становишься глух к окружающим. Последнее, ну и зачем на это время терять, лучше "вздрючить команду" лишний раз.
Возможно, в контексте статьи прозвучит удивительно, но в большинстве теоретической литературы, приводятся аргументы, противоположные первым двум тезисам.
Ну и не стоит забывать про разные точки зрения. "Относятся как к детям" вполне может быть защитой от дурака, которую ввели не просто так. А "лишними тягомотными процедурами" вполне может оказаться стратегическое решение, влияние которого видно только при наличии общей картины, отсутствующей у исполнителя. Да, доносить понимание всего этого - такая же обязанность руководителя, но это лишь говорит о том, что эти три тезиса - не исчерпывающий список и даже не стартовый набор.
уберите везде упоминание про ИТ
Скорее в айти это проявляется наиболее явно. Потому что требования к самостоятельной работе и творческому подходу к процессу там обычно выше.
А ты уверен, что нам нужен именно DynamoDB? Почему эта Lambda-функция использует Python, а не Node?
Ну эти вопросы на самом деле валидные. Например, если все приложения внутри компании пользуют постгрес, и тут вдруг новый сервис на динаме? А у нас набор ДБА, сертифицированный на постгрес, и который в случае возникновения проблем на Динаме никак не поможет. И чего тогда?
Аналогичный вопрос - если все в компании пишут на ноде, включая лямбды, и вдруг начали что-то писать на питоне. С чего вдруг? Т.е. такие внезапные прыжки в экосистемах должны иметь очень серьезное обоснование, желательно записанное где-нибудь.
Вряд-ли рядовой сотрудник, даже сеньор, в крупной компании просто с нуля возьмёт и начнет что-то писать на Node, если все остальное написано на Python?)))) То же самое и про db
А бывает такое, у меня был в команде такой кадр, чуть зазеваешся - он уже ядерный реактор наваял вместо простенькой ф-ции
Или еще были господа которых хлебом не корми - постоянно какието либы левые притаскивали с гитхаба, причем не глядя ни на количество звезд ни на активность проекта
до сих пор у меня проект есть где ктото умный затащил форкнутую версию мигратора для peewee которая заглохла года 3 назад (тамжа такие классные фичи!! нечево самому писать, вон ктото сделал)...и теперь чтобы его обновить на актуальную версию оригинального мигратора (который не дает теперь обновить сам peewee), надо кучу кода отрефакторить...
с тех пор постоянно одергиваю своих падаванов от такого...видимо заставляю их выгорать ;)
а у меня в команде был тимлид, с которым чуть ли не каждую стороннюю
библиотеку нужно было согласовывать и спорить, зачем она нужна в проекте
(правда проекты на Swift/Objective-C, а не на Node.js). Например,
вместо того, чтобы по-быстрому накидать UI, пиши длиннющую и нечитаемую
портянку кода - просто потому, что она предоставляется системой из
коробки.
а вот я согласен с ним, я именно на проекте на Objective-C я напоролся на то что забиндились на либу (чтобы не писать портянки) у которой как выяснилось последний коммит был 5 лет назад...и подъехавшая новая версия ios оказалась с ней несовместима, и пришлось лопатить кучу кода просто чтобы вот.
Маразм иногда доходил до того, что обновляется синтаксис языка - все
равно до победного будем использовать старый синтаксис, пока apple его
окончательно не отключит.
тут уже более спорно
с одной стороны - проект должен следовать общему стилевому гайдлайну, и изменение версии языка чтобы поддерживать новый синтаксис - это отдельный поход с рефакторингом который несет риски и вписываться в него стоит только если есть осознание плюсов для проекта
просто так недумая начинать писать новый код в новом стиле...получится мешанина из старого и нового стиля плюс всякие баги
и MS и Гугл например были замечены в тем что выпускали новые фичи которые через пару месяцев были объявлены устаревшими...и если например в продукте начать сразу писать код с ними - мы устраиваем себе лишнюю попоболь, которая не несет никаких плюсов для бизнеса
А с другой стороны проект надо постоянно подтягивать под актуальную версию стека чтобы не сползать в адское легаси
>а у меня в команде был тимлид, с которым чуть ли не каждую стороннюю библиотеку нужно было согласовывать и спорить
>а вот я согласен с ним, я именно на проекте на Objective-C
Может вы и есть бывший лид@Gargo?)
Такое легко возможно, например когда разработчик изучает новую для себя технологию и хочет её применить в реальности. И он может начать искренне считать что так будет лучше, не совсем осознавая последствия
Да просто либы Python могут в один момент начать сильно отставать, от того что есть в node и вот ты уже пишешь на node. Хотя там не с нуля получается. Про db согласен больше, там до таких проблем ещё дойти надо.
В моем стартапе, в течение того года, когда продукт всё никак не мог дойти до релиза, руководитель какое-то время проводил сбор пожертвований.
Неудачный перевод, судя по контексту это не пожертвования, а очередные раунды инвестиций из за которых доля у всех текущих владельцев акций размывалась.
Бред какой-то. Зачем в таком тратить время своей жизни.
Вы смотрите на процесс со стороны разработчика. Чаще всего боссы всё прекрасно понимают. Но есть компании где задача состоит не в выпуске продукта, а в растягивании этого выпуска. Присасываются к дырявой кормушке и изображают деятельность. Конечно же выявить такую компанию и не попасть в нее (или покинуть) - задача первой важности.
Как-то работал в одном проекте и было всегда ощущение, что там все предложения сэкономить деньги очень негативно воспринимают. А оказалось что это не ощущение, а так и есть: проект был создан под распил бабла. Ух как припекало.
Где-то год проработал в банке. Пилил фичи под вендорский интернет-банк. Таски ставились, фичи пилились, проходили все стадии одобрения и... всё в стол. Редкая фича пролелза на фронт, за год работы можно на пальцах руки пересчитать. И так было не только у интернет банка, но и у карточной системы, и в ядре, и вообще почти во всём dev-отделе. Так и не понял смысла держать отдел разработки в сотню человек (банк небольшой). В итоге версии на проде сильно отличались от staging, баги воспроизводить и чинить на staging или на локальной машине было прям нереально сложно. Примерно раз в три месяца staging синхронизировался с продом, но это спасало ненадолго.
Раз в 3 месяца - для неповоротливого энтерпрайза/финтеха, с миллионами клиентов и миллиардами денег в обороте - это еще не плохо.
Это ведь следствие того, что когда-то выкатили релиз быстро, пропустили баг, потом подсчитали финансовый ущерб от этого бага и от заказчика прозвучало "почему вместо того что бы оплатить еще месяц работы команды и все хорошо проверить, вы приняли решение выкатить версию?"
Да, такие вещи в современной разработке закрываются различными архитектурными решениями и подходами к доставке фичей, но для этого нужно что бы "там наверху" это было нужно. А такие компании как банки и, что удивительно, даже телеком, часто не видят в этом необходимости - и так норм, клиенты деньги и так несут, так что лучше не трогать. Но и необходимость развиваться (когда-нибудь в будущем) тоже понимают. Вот и существует IT-отдел, который что-то такое крутое разрабатывает, но на будущее, и в котором копится снежный ком изменений, риски которого тем больше, чем дольше он копится.
Вот рецепт от нашего нового руководства, всё примерно то же самое, но в максимально сжатые сроки:
1. Приоритет отдаётся неважным и несрочным задачам. С наивысшим приоритетом делаются задачи "в стол". Одновременное количество таких задач в работе у сотрудника неограничено
2. Чем дольше в работе находятся приоритетные задачи, тем лучше. Чтобы максимально задействовать команду при их выполнении, ТЗ должно ежедневно меняться и уточняться. Комментарии могут противоречить друг друг, если между ними прошло достаточно времени. Если какая-то часть проекта была акцептована, важно не забыть поменять это решение на следующий итерации
3. Постановка задач должна быть размыта настолько, чтобы свести к нулю вероятность её правильного выполнения. Попытки конкретизировать ТЗ приравниваются к профнепригодности
4. Вместо донесения важных аспектов задачи и общего видения результата нужно заняться микроменеджментом, ежедневно следить за каждым шагом выполнения задачи, челленджить именно те моменты, где команда все ещё чувствует себя профессионалами
5. Всё вышеописанные действия следует предпринимать не только стандартные 40 часов в неделю, но и (особенно) в нерабочие время. Лучшее время перенести дедлайн на сегодня - 7 вечера, на утро понедельника - вечер субботы
[BONUS] Наибольшую эффективность даст только тотальная практика, важно парализовать деятельность не какой-то одной команды, а бизнеса в целом, чтобы все показатели доходности и присутствия на основных рынков синхронно снижались независимо от предпринимаемых действий сотрудников
Написал коммент из своего опыта, получилось очень длинно и бесполезно - кто в теме, тот и так знает, а другие не поймут.
В итоге остался только один очень простой совет - если проект длинный (2-3 года) и за это время сменились ведущие разработчики и/или архитектор, то ищите новое место работы. Вывод - чем ближе начальник отдела разработки к владельцу бизнеса, тем больший швах в проектах разработки.
Опыт (>5 лет) в компании разработки ПАК сетевых устройств (сисарх, 2-3 года до ретайед)
Доводим разработчика до выгорания: три простых шага