> Не более чем попытка протащить в науку концепцию души, богоданной исключительно человеку.
Человек может отслеживать процесс размышления. Но человек (как минимум двое на планете, за остальных не уверен, но подозреваю) может отслеживать и процесс сознания, отслеживающий процесс размышления. Это и есть способ наблюдения сознания. Душа тут не при чём.
Приведите пример незаменимого специалиста, которого нельзя убрать ни при каких условиях.
Неужели в истории бизнеса вы знаете так мало случаев, когда человек уходил и компания улетала на кладбище? Я уверен, что вы наверняка их знаете немало — так умирает значительная часть малого бизнеса.
За это можно почти Нобелевскую премию же дать.
За то, что главу Арбат-Престижа отправили на полгода в СИЗО и компания прекратила существование? За то, что уход из IT-стартапа на 5-10 человек техдиректора, как правило, приводит к её краху даже если техдиректор оставляет после себя полностью работоспособную, доведённую до боевой эксплуатации и хорошо документированную систему? Это не нобелевское открытие — это будни российского IT-рынка.
Опять же, я вам могу рассказать о том, как при очень средней з/п люди держатся в компании по 7-15 лет, потому что они делают офигенный проект и кайфуют. Просто они сделали выбор не в пользу Мерседеса
Не в пользу своего Мерседеса. Они сделали выбор в пользу того, что Мерседес за их счёт, их потом и кровью, их ночными сверхусилиями, получит владелец компании. Это тоже выбор, но не всегда осознанный. Продали же им это как возможность «полностью раскрыть профессиональные амбиции» — и это уже сознательное выжимание денег из сотрудников.
Есть простой понятный бизнесу бенчмаркинг: посмотреть характеристики по параметрам сайтов-конкурентов для конкретной ниши и сделать чуть лучше. Не идеально, а именно чуть лучше. Минимум затрат — максимум выигрыша.
Это в измеримых величинах. А в реальности всё зависит от того, как посетитель с поисковика использует сайт и возвращается ли с него в поиск для захода на сайты конкурентов — остальное для поисковика лишь вторичные половые признаки.
К сожалению, большинство книг откровенный мусор. Они банально про опенспейсы — пространства смерти для интеллектуальной работы. Из того, что не мусор:
Studio O+A: Twelve True Tales of Workplace Design
Spaces for Innovation: The Design and Science of Inspiring Environments
The New Nomads: Temporary Spaces and a Life on the Move
Но эти три книги, увы, тоже бесполезны в наших реалиях: они про организацию пространства зданий крупных компаний и про неокочевников (много их среди нас?).
До сих пор самой одной из самых качественных книг по организации пространства для IT-профессионалов является книга Peopleware ДеМарко и Листера для водопадной модели разработки. Так же есть дельные описания вариантов организации помещения для XP у Кента Бека в 13 главе книги Экстремальное программирование.
Первой книге 40 лет, второй 20 и ситуация такова, что мы можем только мечтать о том, чтобы российский IT-менеджмент внял хотя бы их банальным рекомендациям по кратному увеличению производительности труда за счёт организации тишины на рабочих местах.
Нет, не жадность. В текущей российской системе разделения труда только так и можно работать.
Это в США по построению экономики на рынке можно найти смежника с любой узкой специализацией (например, маркетинговую фирму специализирующуюся не просто на каком-то рынке, а на узком сегменте рынка — и даже выбрать из нескольких узкоспециализированных фирм). В итоге, каждая компания узко специализируется сама по себе, всю непрофильную деятельность аутсорсит и поэтому может нанимать узких специалистов.
В СССР же с конца 40-х было принято решение строить систему разделения труда на иных основаниях. В итоге, у нас ценятся фирмы широкого профиля, а в силу специфики фирм и специалисты-фуллстеки. Это не жадность. Это следствие того, как устроена наша экономика.
Это какая-то фантастика. Реальность иная: заказчик получил продукт, оплатил его и продукт используется в режиме промышленной эксплуатации. Вот это — успех.
Я работал уже во многих проектах и «острая нехватка времени» — это всегда косяк именно что «манагеров».
Работал в компании где тестов для новой функциональности не писали, но использовали feature tags (Позволяет нажатием одной кнопки в runtime «откатить» свежий код) + регрессивные тесты для сложных случаев(и то в достаточно интересной форме) — если какой то баг все таки вылез. Качество продукта было очень достойным, скорость разработки бешеная. И все вполне себе годами работало и дышало.
Верится с трудом, хотя в жизни всё бывает.
Во-первых, откат кода не решает проблему затрат времени на исправление багов. А править их надо даже если код откатывали. Во-вторых, непокрытый код трудно рефакторить и дорабатывать. Лишь достаточно плотно покрытый тестами код позволяет это делать без страха что-то сломать или не так сделать. В-третьих, как бы кох ни был хорошо структурирован, через какое-то время начинаются проблемы с появлением ошибок не там, где добавляли новый функционал или дорабатывали существующий. Но можно, конечно, жить как Wordpress или github — выпускать релиз без тестирования и по громкости криков пользователей (количеству постов в Твиттере) определять есть ли ошибки в функционале, насколько они критичны и где их искать. Каждому своё.
Да, есть достаточно большое количество компаний, у которых десятки мегабайт кода не покрыты тестами. И значительная часть этого кода — официально признаваемое легаси. Разговариваешь с ними о найме, узнаёшь о том, что они хотели бы перевести проект на современный фреймворк, но по прежнему не хотят покрывать код тестами, и уходишь.
Такое чувство, что автор живёт в Утопии… Если это реально рабочая модель
Она не рабочая. Никому не пожелаю по ней работать. Но по ней временами приходится работать. При всём треше, который должен осознавать любой, кто имел дело с управлением проектами.
Но что если кто-то уходит?
И так можно спросить про каждый элемент: а что, если он оказался ненадёжен. Поэтому описанное не методология, не фреймворк, не руководство, а из жанра «так бывает, так поступали, так сработало и есть понимание, что вот так вот и вот так вот не сработало бы».
ведь по такому «эталону», как требуется в «Разработчиках»… да по нему вообще реально хоть кого-то нанять? Ну реально стоящего?
Да, последние пять проектов в таком режиме вполне себе прошли успешно. В трёх из них разработчиков нанимал и увольнял лично я.
сказать проджектманагеру, что он мудак — тоже запрещается
Людям вообще не стоит говорить, что они мудаки. Мудаки достаточно просто отсеиваются на собеседовании, а с оставшимися вполне можно по-человечески общаться даже в сложных ситуациях.
Вообще какие-то наверное чисто «проджеткменеджерские» закидоны — покоробило.
Никому и не советую так работать. Только дело в таких проектах не в «манагерах», а именно в острой нехватке времени.
Заказчик рулит качеством в плане scope, но он не может физически знать как делать для него работу.
Давайте посмотрим, как это выглядит в действительности. Заказчику продали проект. В договоре что-то написано. Что там написано — это вообще не дело техруководителя. Для этого есть бизнес руководитель проекта. Он получает на входе договор с заказчиком, техническое задание и смету от техруководителя.
Обязанность техруководителя написать грамотное ТЗ и составить к нему смету понятно и достаточно детально. На основе этих входов бизнес руководитель пытается совместить договор, смету и бюджет. При этом техруководитель должен (его обязанность) объяснить бизнес руководителю цену отказа от тех или иных пунктов из сметы, возможные окольные методы снижения стоимости работ и связанные с этим риски.
В случае, если заказчиком выступает бизнес руководитель процедура согласования значительно проще, но понимания обычно меньше — в таких ситуациях бизнес руководитель, зачастую, не знает специфику разработки вообще.
Мне кажется, что выпускать качественное ПО без дефектов это все же задача и ответственность разработчиков, разве нет?
В теории да. На практике нет. На практике лишь единичные заказчики готовы платить за качественное ПО без дефектов и то в очень ограниченном количестве случаев. Под качественным кодом я подразумеваю 1 дефект на 100 тыс. строк кода.
давайте пример как аксиому
Вы теорией занимаетесь или практикой?
Если это дает выигрыш даже на малом масштабе,
Не даёт. Первый месяц разработки без тестов даст на 20% больше кода, чем с тестами, если программисты имеют хорошие навыки написания модульных тестов, и на 50% больше кода, если не имеют. Про качество кода я помолчу.
Это просто заложено в самом TDD, как принцип.
TDD это не про ускорение мелких проектов. TDD — это про то, как снизить экспоненциальную деградацию скорости разработки на длительных периодах разработки и при этом же снизить стоимость исправления ошибок на тех же длительных периодах.
Самый быстрый способ написать приложение малого объёма — говнокод. Это даже у Брукса есть.
Потому что не надо спрашивать — а не соблаговолите ли вы приостановить работу на месяц, т.к. мы грязно работали и надо наводить порядок? Если время на написание тестов по каждой задаче сразу заложить и никого не спрашивать — то и убеждать никого не надо будет.
В теории всё прекрасно. Особенно с обманом других участников команды управления. Но вообще-то это должностное преступление. Не технический руководитель проекта принимает решение о качестве продукта. Не в его это ведении. А вот что находится в обязанностях технического руководителя, так это донести понимание как получить разное качество продукта при разной стратегии управления разработкой и добиться его при принятии решения.
И да, даже если бы это не было должностным преступлением, то всё равно так поступать не следует. Взаимное доверие является критически важным ресурсом при принятии решений. Это трудно объяснить словами, но это невозможно не почувствовать на практике.
Формально можно, на практике это выстрел самому себе как минимум в ногу. Рефакторить же будет нельзя эффективно. Плюс потом уже тесты будут подгоняться под имеющйися код, а не описывать изначально поставленные задачи, ну и т.п. Последствий будет много и все неприятные. Полгода — это много.
Да, полгода — это много. Да — выстрел в ногу. Да — рефакторить будет проблемно. В толковом проекте вся команда управления это понимает, но сделать ничего не может — сроки и объёмы уже проданы.
В такой ситуации необходим тимлид, который хорошо умеет писать модульные тесты и любит это дело. Одной из его задач будет отсматривать код и оценивать его на покрываемость тестами. Он по коду должен понять покрываем ли данный код тестами в принципе, насколько его легко покрыть и не стал ли он после очередной правки непокрываем. Если код трудно покрыть тестами, то задача возвращается разработчику с описанием как следует переписать данный участок кода, а иногда и с прямой ссылкой на наиболее подходящий шаблон проектирования.
Да, это тоже не панацея ни разу. Но именно так можно тянуть 7-9 месяцев без активного рефакторинга не покрывая код модульными тестами. Потом приходится отводить несколько недель на рефакторинг наиболее проблемных участков кода и начинать активно покрывать код тестами. Думаю, результат такого подхода для всех предсказуем.
Человек может отслеживать процесс размышления. Но человек (как минимум двое на планете, за остальных не уверен, но подозреваю) может отслеживать и процесс сознания, отслеживающий процесс размышления. Это и есть способ наблюдения сознания. Душа тут не при чём.
P.S. Взгляд прошаренного 1С-ника на Data Science и как его можно подать доставляет, да.
Вы правы. Не должен. Выживание — дело добровольное.
Неужели в истории бизнеса вы знаете так мало случаев, когда человек уходил и компания улетала на кладбище? Я уверен, что вы наверняка их знаете немало — так умирает значительная часть малого бизнеса.
За то, что главу Арбат-Престижа отправили на полгода в СИЗО и компания прекратила существование? За то, что уход из IT-стартапа на 5-10 человек техдиректора, как правило, приводит к её краху даже если техдиректор оставляет после себя полностью работоспособную, доведённую до боевой эксплуатации и хорошо документированную систему? Это не нобелевское открытие — это будни российского IT-рынка.
Не в пользу своего Мерседеса. Они сделали выбор в пользу того, что Мерседес за их счёт, их потом и кровью, их ночными сверхусилиями, получит владелец компании. Это тоже выбор, но не всегда осознанный. Продали же им это как возможность «полностью раскрыть профессиональные амбиции» — и это уже сознательное выжимание денег из сотрудников.
Это в измеримых величинах. А в реальности всё зависит от того, как посетитель с поисковика использует сайт и возвращается ли с него в поиск для захода на сайты конкурентов — остальное для поисковика лишь вторичные половые признаки.
Но эти три книги, увы, тоже бесполезны в наших реалиях: они про организацию пространства зданий крупных компаний и про неокочевников (много их среди нас?).
До сих пор самой одной из самых качественных книг по организации пространства для IT-профессионалов является книга Peopleware ДеМарко и Листера для водопадной модели разработки. Так же есть дельные описания вариантов организации помещения для XP у Кента Бека в 13 главе книги Экстремальное программирование.
Первой книге 40 лет, второй 20 и ситуация такова, что мы можем только мечтать о том, чтобы российский IT-менеджмент внял хотя бы их банальным рекомендациям по кратному увеличению производительности труда за счёт организации тишины на рабочих местах.
Нет, не жадность. В текущей российской системе разделения труда только так и можно работать.
Это в США по построению экономики на рынке можно найти смежника с любой узкой специализацией (например, маркетинговую фирму специализирующуюся не просто на каком-то рынке, а на узком сегменте рынка — и даже выбрать из нескольких узкоспециализированных фирм). В итоге, каждая компания узко специализируется сама по себе, всю непрофильную деятельность аутсорсит и поэтому может нанимать узких специалистов.
В СССР же с конца 40-х было принято решение строить систему разделения труда на иных основаниях. В итоге, у нас ценятся фирмы широкого профиля, а в силу специфики фирм и специалисты-фуллстеки. Это не жадность. Это следствие того, как устроена наша экономика.
Это специфика советской системы разделения труда. У американской системы разделения труда противоположная специфика — узкая специализация.
В этом плане совершенно согласен.
Во-первых, откат кода не решает проблему затрат времени на исправление багов. А править их надо даже если код откатывали. Во-вторых, непокрытый код трудно рефакторить и дорабатывать. Лишь достаточно плотно покрытый тестами код позволяет это делать без страха что-то сломать или не так сделать. В-третьих, как бы кох ни был хорошо структурирован, через какое-то время начинаются проблемы с появлением ошибок не там, где добавляли новый функционал или дорабатывали существующий. Но можно, конечно, жить как Wordpress или github — выпускать релиз без тестирования и по громкости криков пользователей (количеству постов в Твиттере) определять есть ли ошибки в функционале, насколько они критичны и где их искать. Каждому своё.
Да, есть достаточно большое количество компаний, у которых десятки мегабайт кода не покрыты тестами. И значительная часть этого кода — официально признаваемое легаси. Разговариваешь с ними о найме, узнаёшь о том, что они хотели бы перевести проект на современный фреймворк, но по прежнему не хотят покрывать код тестами, и уходишь.
И так можно спросить про каждый элемент: а что, если он оказался ненадёжен. Поэтому описанное не методология, не фреймворк, не руководство, а из жанра «так бывает, так поступали, так сработало и есть понимание, что вот так вот и вот так вот не сработало бы».
Да, последние пять проектов в таком режиме вполне себе прошли успешно. В трёх из них разработчиков нанимал и увольнял лично я.
Людям вообще не стоит говорить, что они мудаки. Мудаки достаточно просто отсеиваются на собеседовании, а с оставшимися вполне можно по-человечески общаться даже в сложных ситуациях.
Никому и не советую так работать. Только дело в таких проектах не в «манагерах», а именно в острой нехватке времени.
Давайте посмотрим, как это выглядит в действительности. Заказчику продали проект. В договоре что-то написано. Что там написано — это вообще не дело техруководителя. Для этого есть бизнес руководитель проекта. Он получает на входе договор с заказчиком, техническое задание и смету от техруководителя.
Обязанность техруководителя написать грамотное ТЗ и составить к нему смету понятно и достаточно детально. На основе этих входов бизнес руководитель пытается совместить договор, смету и бюджет. При этом техруководитель должен (его обязанность) объяснить бизнес руководителю цену отказа от тех или иных пунктов из сметы, возможные окольные методы снижения стоимости работ и связанные с этим риски.
В случае, если заказчиком выступает бизнес руководитель процедура согласования значительно проще, но понимания обычно меньше — в таких ситуациях бизнес руководитель, зачастую, не знает специфику разработки вообще.
Вы теорией занимаетесь или практикой?
Не даёт. Первый месяц разработки без тестов даст на 20% больше кода, чем с тестами, если программисты имеют хорошие навыки написания модульных тестов, и на 50% больше кода, если не имеют. Про качество кода я помолчу.
TDD это не про ускорение мелких проектов. TDD — это про то, как снизить экспоненциальную деградацию скорости разработки на длительных периодах разработки и при этом же снизить стоимость исправления ошибок на тех же длительных периодах.
Самый быстрый способ написать приложение малого объёма — говнокод. Это даже у Брукса есть.
И да, даже если бы это не было должностным преступлением, то всё равно так поступать не следует. Взаимное доверие является критически важным ресурсом при принятии решений. Это трудно объяснить словами, но это невозможно не почувствовать на практике.
В такой ситуации необходим тимлид, который хорошо умеет писать модульные тесты и любит это дело. Одной из его задач будет отсматривать код и оценивать его на покрываемость тестами. Он по коду должен понять покрываем ли данный код тестами в принципе, насколько его легко покрыть и не стал ли он после очередной правки непокрываем. Если код трудно покрыть тестами, то задача возвращается разработчику с описанием как следует переписать данный участок кода, а иногда и с прямой ссылкой на наиболее подходящий шаблон проектирования.
Да, это тоже не панацея ни разу. Но именно так можно тянуть 7-9 месяцев без активного рефакторинга не покрывая код модульными тестами. Потом приходится отводить несколько недель на рефакторинг наиболее проблемных участков кода и начинать активно покрывать код тестами. Думаю, результат такого подхода для всех предсказуем.