Если смотреть на разработку и командную работу, как на набор бесконечных пожаров в условии дефицита ресурсов (руки, время), то да - всегда будет что-то более приоритетное, вопросов нет. Но не надо из-за этого делать выводы о других проектах.
Если же есть хоть какая-то перспектива на разгребание техдолга, то внедрение инструментов качества кода, таких как линтеры, форматеры и т.д. - хороший шаг для начала. Затраты на эти изменения низкие, а пользу начинает приносить быстро - код становится более читаемым и упрощается код-ревью (больше смотрим на суть, а не на скобочки). И вот уже у Вашей команды больше времени и сил на что-то посерьезнее.
Стратегию внедрения Вы сами можете продумать, учитывая реалии проекта. Например, можно прописать исключения на ту часть проекта, которая в данный момент не разрабатывается активно. И постепенно расширять область, где правила работают в полном объеме.
Код надо держать в здоровом состоянии, тогда над проектом будет легче работать
Спасибо, что пояснили. Я с Вами согласен, не все смогут и не всем надо. А навязывание, что всем надо - это плохо.
Но тем не менее, я считаю, что взять в свою работу какие-то практики можно, пусть даже это и не приведет к смене должности. Например, плохого от чтения кода не случится. Я же самом-то деле не о должностях, а о мышлении, как его развивать. И я старался сделать текст короче, не расползаясь в пояснения по связанным вопросам. Поэтому есть ряд упрощений, в том числе и в заголовке
Вы приводите вопросы управления (кому какие задачи оптимально отдавать), они в статье не затрагивались, это отдельная тема. Ну то есть, допустим, какие-то задачи кому-то давать неоптимально. Как от этого меняются подходы к саморазвитию разработчика?
Вот это слишком категоричное утверждение.
если пытаться в паре строк описать ситуацию, то упрощения неизбежны. Я согласен с Вами, что бывают исключения и нельзя судить о професиональных качествах конкретнго человека по некой усредненной модели
та, ситуация, о которой Вы говорите - это крайность и плохая практика, не надо до этого доводить работу в команде. Я этого не имел ввиду, мне жаль, если Вы сделали такой вывод. Тезис был в том, что обычно синьор лучше мидла справляется в условиях недостатка информации. И эта ситуация недостатка информации встречается чаще, чем хотелось бы, по разным причинам, не только из-за управления. Например, может не быть хорошей доки по опенсорсному проекту, который надо интегрировать
вижу, что это место зацепило не только Вас) Надо было написать - идея по именованию. Я поправлю, чтобы обсуждение статьи не сводилось к обсуждению одной фразы.
Как бы то ни было, та фраза - это не вывод, и не основная мысль.
Но разве сделать проект более понятным и надежным для планирования - не задача команды?
То, что Вы описываете - это распространненая ситуация, я согласен. Но помимо проблем с планированием это еще приводит к ряду неудобств - сложно онбордить новых людей и сложно делать изменения, потому что могут быть неочевидные связи и побочные эффекты.
Ваш вопрос про конкретную ситуацию - вот есть задача (что сделать), сколько это займет времени? И я с Вами согласен, что в условиях проекта, где настолько большие затраты на анализ кода, что-то планировать сложно. Мой ответ в том, что надо делать проект удобным для всех аспектов работы - планирования, внесения изменений, расширения функцоинальности, тестирования, отладки, релиза. И чтобы нетиповые случаи постепенно становились типовыми, то есть снижать сложность проекта.
Спасибо, что пояснили. Я добавил в статью простые диграммы Ганта для наглядности. Думаю, стало лучше.
По образованию - не уверен, думаю дело обстоит сложнее. Ну во-первых, много ли в IT людей с техническим образованием? Не думаю, что больше половины. Я сам, например, без технического образования.
Во-вторых, во время учебы что-то могло отложиться в памяти, а могло и не отложиться. Это то же самое, что сказать - в школе все учили химию, значит должны уметь делать расчет количества вещества. Или была же начерталка, иди нарисуй деталь.
Если работа связана с транспортировкой грузов, то наверно участники процесса должны знать, что существуют разные виды грузов со своими требованиям. Это часть профессии. В варианте, когда сегодня маляр, завтра экспедитор, потом кто-то ещё действительно будет много не учтенных рисков и план не сработает.
Что дальше? Исполнитель на полпути сломает ногу и из этого надо сделать вывод, что планирование не работает?
Я предложил способы, которые работали на разных проектах, в разных компаниях. Такого опыта, как Вы описываете, у меня не было. Бывало всякое, но как-то находились варианты.
Это хорошее замечание. Возможно стоит пересмотреть архитектуру или дизайн кода, если текущая реализация не соответствует новым требованиям. Я думаю, что это обычная история, когда существующую кодовую базу надо переосмыслить
То есть если ситуация, описанная Вами, повторяется регулярно, то это может быть симптомом.
Это я без всякого сарказма, если что. Сам регулярно сталкиваюсь с тем, что оценки по какой-то части продукта хронически неверные. Это повод подумать над рефакторингом
Хорошо, что Вы приводите контрпример. Но является ли Ваш случай обычным или скорее исключением? У любого подхода есть область оптимального применения, и есть ограничения. Я указал это в статье:
Да, существуют проекты, в которых гораздо больше неизвестных
В Вашем примере с городом N надо собрать больше информации, например, связаться с кем-то из его жителей. В данном случае это и будет эксперт по проблеме, подскажет Вам варианты, как добраться. На основе этой информации построите план.
Любо провести эксперимент или серию экспериментов. Это подход, который предлагается для запутанных систем по модели Кеневин. Серия экспериментов не вписывается в бюджет, поэтому давайте лучше уточним информацию у жителей города N
Хорошей практикой является, по возможности, давать оценивать задачи тому что ближе и лучше знаком с её контекстом, подводными камнями и у кого более полная картина о том что нужно вообще будет сделать.
Да, но добавлю, что может быть и другой подход - оценивающий собирает подробности у тех, кто знаком с предметной областью, и строит план на основе этого. Почему так? Навыки планирования могут быть развиты у одного, а с предметной областью работает другой и за деревьями он не видит леса. Да и если проект крупный, то экспертов может быть несколько, а план в итоге один надо составить
Давайте чуть шире посмотрим на ситуацию. Я думаю, что у среднего разработчика нет навыков планирования. С этой проблемой я сталкиваюсь постоянно. И я хотел сформулировать некоторый минимальный, но достаточный набор приемов, которые можно брать и использовать.
Диаграмма Ганта, книги Голдратта и т.д. - это важно, но я хотел рассказать наиболее просто. И чтобы применить можно было даже к небольшой задаче. Ведь там тоже часто бывают промашки по срокам. Я не думаю, что софт типа MS Project стоит использовать, когда разработчику надо назвать срок готовности фичи, состоящей из трех-пяти задач. Да, какие-то моменты в статье были под чуть больший масштаб, на вырост. Но я думаю это неплохо, когда логика планирования прозрачна для всех участников команды.
Если же планирование является основной работой, как, допустим, у проджект-менеджера, то врядли ему поможет статья типа этой
Если смотреть на разработку и командную работу, как на набор бесконечных пожаров в условии дефицита ресурсов (руки, время), то да - всегда будет что-то более приоритетное, вопросов нет. Но не надо из-за этого делать выводы о других проектах.
Если же есть хоть какая-то перспектива на разгребание техдолга, то внедрение инструментов качества кода, таких как линтеры, форматеры и т.д. - хороший шаг для начала. Затраты на эти изменения низкие, а пользу начинает приносить быстро - код становится более читаемым и упрощается код-ревью (больше смотрим на суть, а не на скобочки). И вот уже у Вашей команды больше времени и сил на что-то посерьезнее.
Стратегию внедрения Вы сами можете продумать, учитывая реалии проекта. Например, можно прописать исключения на ту часть проекта, которая в данный момент не разрабатывается активно. И постепенно расширять область, где правила работают в полном объеме.
Код надо держать в здоровом состоянии, тогда над проектом будет легче работать
Спасибо, что пояснили. Я с Вами согласен, не все смогут и не всем надо. А навязывание, что всем надо - это плохо.
Но тем не менее, я считаю, что взять в свою работу какие-то практики можно, пусть даже это и не приведет к смене должности. Например, плохого от чтения кода не случится. Я же самом-то деле не о должностях, а о мышлении, как его развивать. И я старался сделать текст короче, не расползаясь в пояснения по связанным вопросам. Поэтому есть ряд упрощений, в том числе и в заголовке
поясните, пожалуйста, про обесценивание, может я Вас неправильно понял.
Я эту тему не затрагивал, но Вы об этом говорите. Вы увидели попытки обесценивания в статье?
Вы приводите вопросы управления (кому какие задачи оптимально отдавать), они в статье не затрагивались, это отдельная тема. Ну то есть, допустим, какие-то задачи кому-то давать неоптимально. Как от этого меняются подходы к саморазвитию разработчика?
если пытаться в паре строк описать ситуацию, то упрощения неизбежны. Я согласен с Вами, что бывают исключения и нельзя судить о професиональных качествах конкретнго человека по некой усредненной модели
поясните, что вы имеете ввиду под этими словами.
Внедрение - что внедряем и куда?
Развертывание и сопровождение - это экплуатация сервиса? в тексте есть про это, целый раздел
ок, допустим это мой личный недостаток, слишком парюсь с именованием, поэтому идею по удачному именованию оценил выше, чем оно того заслуживает.
Но это не было выводом статьи или чем-то, что я предлагаю.
Мне было бы более интересно обсудить рекомендации из статьи
та, ситуация, о которой Вы говорите - это крайность и плохая практика, не надо до этого доводить работу в команде. Я этого не имел ввиду, мне жаль, если Вы сделали такой вывод. Тезис был в том, что обычно синьор лучше мидла справляется в условиях недостатка информации. И эта ситуация недостатка информации встречается чаще, чем хотелось бы, по разным причинам, не только из-за управления. Например, может не быть хорошей доки по опенсорсному проекту, который надо интегрировать
вижу, что это место зацепило не только Вас)
Надо было написать - идея по именованию. Я поправлю, чтобы обсуждение статьи не сводилось к обсуждению одной фразы.
Как бы то ни было, та фраза - это не вывод, и не основная мысль.
Но разве сделать проект более понятным и надежным для планирования - не задача команды?
То, что Вы описываете - это распространненая ситуация, я согласен. Но помимо проблем с планированием это еще приводит к ряду неудобств - сложно онбордить новых людей и сложно делать изменения, потому что могут быть неочевидные связи и побочные эффекты.
Ваш вопрос про конкретную ситуацию - вот есть задача (что сделать), сколько это займет времени? И я с Вами согласен, что в условиях проекта, где настолько большие затраты на анализ кода, что-то планировать сложно. Мой ответ в том, что надо делать проект удобным для всех аспектов работы - планирования, внесения изменений, расширения функцоинальности, тестирования, отладки, релиза. И чтобы нетиповые случаи постепенно становились типовыми, то есть снижать сложность проекта.
Спасибо, что пояснили. Я добавил в статью простые диграммы Ганта для наглядности. Думаю, стало лучше.
По образованию - не уверен, думаю дело обстоит сложнее. Ну во-первых, много ли в IT людей с техническим образованием? Не думаю, что больше половины. Я сам, например, без технического образования.
Во-вторых, во время учебы что-то могло отложиться в памяти, а могло и не отложиться. Это то же самое, что сказать - в школе все учили химию, значит должны уметь делать расчет количества вещества. Или была же начерталка, иди нарисуй деталь.
Если работа связана с транспортировкой грузов, то наверно участники процесса должны знать, что существуют разные виды грузов со своими требованиям. Это часть профессии. В варианте, когда сегодня маляр, завтра экспедитор, потом кто-то ещё действительно будет много не учтенных рисков и план не сработает.
Что дальше? Исполнитель на полпути сломает ногу и из этого надо сделать вывод, что планирование не работает?
Я предложил способы, которые работали на разных проектах, в разных компаниях. Такого опыта, как Вы описываете, у меня не было. Бывало всякое, но как-то находились варианты.
Как Вы сами справляетесь с такими трудностями?
Это хорошее замечание. Возможно стоит пересмотреть архитектуру или дизайн кода, если текущая реализация не соответствует новым требованиям. Я думаю, что это обычная история, когда существующую кодовую базу надо переосмыслить
То есть если ситуация, описанная Вами, повторяется регулярно, то это может быть симптомом.
Это я без всякого сарказма, если что. Сам регулярно сталкиваюсь с тем, что оценки по какой-то части продукта хронически неверные. Это повод подумать над рефакторингом
Некоторый инструментарий все же у нас есть и на этот случай
Прототипирование. То есть некий дешёвый вариант проверить идею и увидеть проблемы или, наоборот, повысить уверенность и начать финальную реализацию
Ранняя интеграция, чтобы все компоненты можно было соединить как можно раньше и собрать фидбэк или вообще увидеть, что получается
100-процентной гарантии это конечно не даёт, но шансы на успех должно повысить. Я наверно дополню немного статью, спасибо
Хорошо, что Вы приводите контрпример. Но является ли Ваш случай обычным или скорее исключением? У любого подхода есть область оптимального применения, и есть ограничения. Я указал это в статье:
В Вашем примере с городом N надо собрать больше информации, например, связаться с кем-то из его жителей. В данном случае это и будет эксперт по проблеме, подскажет Вам варианты, как добраться. На основе этой информации построите план.
Любо провести эксперимент или серию экспериментов. Это подход, который предлагается для запутанных систем по модели Кеневин. Серия экспериментов не вписывается в бюджет, поэтому давайте лучше уточним информацию у жителей города N
Да, но добавлю, что может быть и другой подход - оценивающий собирает подробности у тех, кто знаком с предметной областью, и строит план на основе этого. Почему так? Навыки планирования могут быть развиты у одного, а с предметной областью работает другой и за деревьями он не видит леса. Да и если проект крупный, то экспертов может быть несколько, а план в итоге один надо составить
Давайте чуть шире посмотрим на ситуацию. Я думаю, что у среднего разработчика нет навыков планирования. С этой проблемой я сталкиваюсь постоянно. И я хотел сформулировать некоторый минимальный, но достаточный набор приемов, которые можно брать и использовать.
Диаграмма Ганта, книги Голдратта и т.д. - это важно, но я хотел рассказать наиболее просто. И чтобы применить можно было даже к небольшой задаче. Ведь там тоже часто бывают промашки по срокам. Я не думаю, что софт типа MS Project стоит использовать, когда разработчику надо назвать срок готовности фичи, состоящей из трех-пяти задач.
Да, какие-то моменты в статье были под чуть больший масштаб, на вырост. Но я думаю это неплохо, когда логика планирования прозрачна для всех участников команды.
Если же планирование является основной работой, как, допустим, у проджект-менеджера, то врядли ему поможет статья типа этой