Comments 115
Честно признаюсь, не очень мне нравятся посты и комменты этого автора, большей частью из-за стиля общения и позиции и вот теперь я понял почему. (минусов в карму я вам не ставил ещё)
Однако, должен признать, что, в принципе, вопрос поднят хороший. Нехотя поставил статье плюс, хотя и не согласен в целом снова (ну да, тогда я сразу я человек-сосед, ок).
Главная претензия - не надо обобщать.
Хорошо, вы построили дом себе, без опыта и умений. А если вам поручить построить дом на 300 человек в месте где нет коммуникаций и дорог - что из этого выйдет? Сколько вам на это надо времени? А денег? А через сколько лет он упадёт?
Иногда мы все скучаем по временам когда не было деплоев, можно было есть яблоки с ветки, а новое лекарство от тошноты для беременных можно было выпустить сразу после получения в пробирке и не заморачиваться с бумажками.
Правы же вы в том, что, действительно, есть случаи когда люди слишком переусложняют процесс, но есть тонкая грань и никогда не известно что может случиться дальше.
"Положить в докер, докер в кубернетес, кубернетус в опеншифт, опеншифт в . …"
но эта современная матрешечная виртуализация реально за гранью
Я рабочие машины для удаленных сотрудников вывел из гипервизора, теперь сидят толпой в RDP терминале физической win 10 и не жужжат.
"А если вам поручить построить дом на 300 человек в месте где нет коммуникаций и дорог - что из этого выйдет" Если у меня нет компетенций, чтоб строить небоскрёб, я как человек-конец в цикле сделаю 500 идентичных одноэтажек - это будет дешевле и быстрее. И у меня не будет проблем с землетрясениями, под станциями на 50-м этаже, обледенинениями и фонарями на крыше от самолётов.
Скажите мне удобно расселить 500 человек, я сделаю легко быстро и дешево, скажите мне это сделать методом постройки небоскрёба - я сломаюсь.
Я, Даннинг и Крюгер с вами не согласны. Простите, но этот ваш комментарий - полная глупость.
Одноэтажная Америка это для вас какая то шутка?:) Хватит с вашими кентами ярлыки самозванца навешивать ))
Даник и Крюгер абсолютно правы. Сильный ударит, быстрый убежит, хитрый обманет. Не компетентный и бедный решит легко и дешево.
некомпетентный возьмется решать, на полпути попадёт в тупик, попробует пофиксить костылями и угробит всё окончательно.
В этом и разница между компетентностью и некомпетентностью.
Компетентный строитель знает, что для строительства здания выше некоторой величины нужно менять подход. Некомпетентный думает "3 или 10 этажей, какая разница?". Кстати, это отлично видно в Индии: там местные выше трёх (изредка четырёх) этажей не строят. Не потому, что не надо, а потому что с их подходами оно рухнет, и они это знают по своему печальному опыту.
Отмечу, что я не говорю про проекты, которые только заказчику кажутся сложными, а в реальности - простые. Да, они бывают, но эффект Даннинга-Крюгера не про них.
А если задача будет "построить городское метро", то, видимо, запустите кикшеринг? просто потому, что он вам понятнее?
Все просто, на самом деле, выбранный подход у управлению должен соответствовать масштабу и специфике задачи, вот и все. Отклонение как в сторону излишнего упрощения, так и в сторону ненужного усложнения ни к чему хорошему не приведут.
ВНИМАНИЕ У НАС ЕЩЕ ОДИН УПРОСТИТЕЛЬ. возможно человек-МЕНЕДЖЕР
в сторону излишнего - плохо, в сторону не излишнего - хорошо
в сторону ненужного - плохо, в сторону нужного - хорошо.
за все хорошее против всего плохого :) и подход должен соответствовать.
Неудачный пример. В Томске(вроде) построили метро из одной станции)) Насколько денег хватило) И что? Может правда нужно было сделать кикшеринг на эти деньги?
Это был Омск. И её сейчас собираются продавать. То есть сейчас можно купить себе личное метро.
Вы сами привели пример человека-конец из вашего опуса. Томск, Омск, какая разница, задача написать комментарий, я написал, конец. Скачут по верхам, позади выжженная пустыня, впереди светлое будущее, разгребать mvp выданные за продукт будет кто-то другой.
Я вам так скажу. Построить газобетонную дачку может любой, кого не забанили на ютубе. Никакого сопромата там нет, все просто и примитивно. И его 300 метровую дачку я построил бы дешевле и быстрее.
Если вам нужно построить допустим многоэтажку, вам уже стоит нанимать не меня, но профессионального строителя. А я программист. И проблема в том, что строители тоже делятся на 2 категории: концы и соседи. И если вы скажете, что вам нужна 9-этажка площадью 10к квадратных метров, то один строитель построит ее вам за полгода и 200 миллионов. А другой через 6 лет предъявит вам бетонный каркас, потратив миллиард и попросит еще 2 миллиарда и 10 лет.
И моя статья, как нанять того спеца который вас устроит по срокам и качеству. Скорее двух, которые будут уравновешивать друг-друга.
Если вам нужно приложение то вы тоже можете найти двух программистов: Конца и соседа. Я сделаю за полгода, и мне хватит 5 человек, другой сделает за пять лет и ему хватит 100 человек. Или не сделает. Но у меня будет простое и надежное как лом решение, легкое для масштабирования и без багов. У него будет лом с лазерной наводкой и гиростабилизацией из вольфрам-ванадиевого сплава по итальянским лекалам и пофиг, что вам надо лед сколачивать раз в год на даче.
И второй момент - все больше зависит от заказчика. Это больше про него - конец он или сосед. Заказчикам тоже может подсознательно нравится процесс строительства. Да и не подсознательно. Да и у моего соседа, это может быть хобби, а то он может от жены просто на стройке дачи прячется))) Как потратить в 10 раз больше денег? Постоянно меняйте техзадания, чрезмерно усложняйте БП, лезьте в технические решения, устраивайте совещания - требуйте самого нового и модного и кнопочку подвинуть правее. И готово - систему электронного документооборота делают 200 человек пятый год.
Ни за что не доверил бы свою жизнь человеку-концу. Может быть он и завершит сложную операцию, но не уверен, что жить я после этого буду и тем более долго.
It depends. У меня дед полковник и военный хирург в афгане был. Если хронически панкреатит лечит - то вероятно вдумчиво, если травмы на войне - то быстро и эффективно.
Ещё раз, конец может быть абсолютно бесполезен, он эффективен на некоторых конкретных задачах.
Еще может быть такой кейс: лучше плохо, но сейчас, чем хорошо, но уже, быть может, никогда. В ситуациях, где важно время, решения могут быть менее аккуратными, важнее сам факт выполнения задачи, а не идеальность решения.
Главное чтобы потом жена из быстро и дёшево в долго и качественно к соседу не сбежала:) она тоже может оказаться продуманным достигатором
-типичный bugfow человека-соседа
подскажите, а в какой программе сверстан этот миндмап?
Местами это настолько отвратительно, что даже прекрасно :)
С челвеком-концом, когда он product owner или лид в той же кепке есть две проблемы:
а) иногда контекст перестаёт лезть в голову. И мало кто в таких случаях начинает его делить на куски. Потому что "и так понятно как делать" и что нужно получить в итоге. А это не работает для 80% коллег, только если рядом в команде не такие же сидят, и вы не обзавелись общим позитронным полем.
б) bus factor, который в такой схеме равен 1.
По остальным пунктам пройдусь:
То, что какой-то мудрец сделал статусную модель в IDEF0 - ну добра ему. За такую диаграмму надо убивать конечно. Но и управляемости без формального процесса фиг достигнешь, особенно с человеком "ну-я-делаю", который за 32 списанных рабочих часа не сделал ни одного коммита. И не отладкой занимался, вполне себе пилил фичу по разжёванной постановке. Но не пришёл вовремя сказать, что аналитик накосячил, и две части постановки противоречат друг другу.
О да. Логи, логи ещё не забудьте засунуть внутрь контейнера и прикрутить к ним кибану-логстеш-херню на верёвочке, чтобы не дай Бог кто-нибудь бы не пошёл грепать и не обнаружил проблему быстро. Особенно доставляет, когда контейнер виснет и не пишет вообще ничего. Happy Debug! А! забыл. Конфиги туда же, которые куда-то там запечены и перезаписывают тобой же сделанные изменения, ну чтобы нельзя было поправить, перезапустить и посмотреть, как там оно.
Хрен вам, а не push в devel. Да и MR не спасают иногда. Тут матом не ругаются. но очень хочется. Подход "да, я запушил херню которая O(n^2), и что?" потом неприятно удивляет на проде. Потому что тестеры, ****, тоже проверяли на таблице из пяти записей. Но если у вас общее позитронное поле - то ускоряет разработку 10x.
Если человек-конец олимпиадник и ёмкости мозга хватает - то да, тесты нафиг не нужны. А вот если заказчик намутил процесс с семью вариантами начала (передаю привет банковским продуктологам) и восьмью - конца, то без 56 тестов (ладно, шучу, достаточно 15 основных и ещё двух для случая, когда одна или две из семи перпендикулярных красных линий прозрачные) хрен убедишься, что вообще код обрабатывает все варианты. Я ещё и покрытие смотрю на чтении MR, а иногда и мутационное тестирование запускаю. Но я токсичный мудак, судя по реакции некоторых коллег на замечания к коду.
Плюс итерационности - когда вы понимаете, что сделать нужный функционал в указанное время не получается. Но надо, ибо бигбоссы уже что-то кому-то пообещали. Тогда сначала мы делаем, чтобы работал один хардкодед вариант из четырёх, на следующей итерации прикручиваем все четыре (выкидывая первый), а если доживём - редактор, который позволит аналитику на стороне клиента нафигачить ещё тридцать четыре.
Добавлю: если по результатам совещания не родилась задача / письма / статья в KB - оно вам нафиг было не нужно. И не говорите мне про "мы обсудили и разобрались". Всегда найдётся человек [1..*] из присутствующих, который понял не так и взялся с энтузиазмом делать, и ещё один, которому надо, но он не был на совещании, и нужно всё рассказывать заново.
И последнее. " - Дайте мне автомат Калашникова и магазин патронов, и я сделаю мир лучше. - Но ведь магазина не хватит. - Я и не говорю, что сделаю мир совершенным. Но он станет лучше"
Насчет бас фактора. Человек конец, сделает все максимально просто. В Примере с домами, пока сосед будет строить небоскрёб, я сделаю 500 газобетонных одноэтажных домов, абсолютно одинаковых. Обслужить их может кто угодно. Там нет высокоскоростных лифтов, сложной вентиляции или канализации высокого давления. Конфлюенс и документация не нужна.
так не везде можно построить 500 одноэтажных домов, например в центре большого города. поэтому там и строют небоскребы.
Однако небоскрёб будет дешевле и проще. Не надо делать 500 проектов на газ-воду-канализацию-электричество, не надо строить 10...20 км подъездных дорог и заборов, меньше расходы на отопление и обслуживание. Поэтому иногда выгодней усложнить но сделать лучше, чем упростить, тяп-ляп и в продакшн.
Я так понимаю оптимум лежит где-то в районе хрущевок(4-х этажек).
Небоскреб при любом раскладе дороже и в постройке и в обслуживании, мож на отопления можно сэкономить.
В смысле 500 идентичных проектов на воду сложнее сделать, чем систему водоснабжения для небоскрёба? Какой насос нужен, чтоб воду закачивать на 101 этаж? Представляете какое там давление?
Все это знакомо.
В целом разработка - процесс творческий, так что на конкретные сроки он не ложится, все зависит, если угодно, от музы.
Конечно всегда много шаблонной и более-менее предсказуемой рутины, но бывают и творческие задачи, или задачи на удачу, за которые никто не скажет как ее решить, и возможно ли ее решить в принципе.
Бывает на задачу выделено 40 часов бюджета, и первые 30 уходят на то, чтобы понять как к ней подступиться - в эти 30 часов могут быть перебрано несколько решений, от которых придется отказаться на той или иной стадии, кода вообще может не быть, потому что тупо крутишь идеи в голове и обсасываешь их, пока не проявится смутное чувство близости победы, "хм, а ведь если сделать вот так, то быть может все получится как надо, или хотя бы будем на шаг ближе к решению". Это как шахматная партия. И победить можно не всегда, но очень хочется.
Над одной из таких проблем пришлось несколько суток размышлять, делать предположения, опровергать их, отвергать идеи и решения, в итоге озарение пришло за полсуток до срока, который выделил на поиск решения или отказ. Смутная идея того, как раскусить проблему, пришла под струями душа, вечером, "ниоткуда" - мысль просто всплыла откуда-то из глубин. Думаю так мозг доносит результаты своей фоновой активности: частенько бывает, что решения приходят сами собой, если заранее загрузить в себя проблему, а потом просто заняться чем-то другим, через некоторое время решение просто начнет крутиться в голове, хотя сознательно им никто не занимался. Идея была смутной, и нестандартной, в эту сторону еще не думал ни я, ни мои предшественники, и чувствовалось что проработка этой идеи может либо приблизить к решению, либо щать само решение, так что с этой идеей было решено переспать, чтобы мозг дополнительно ее покрутил в фоне, как он это умеет. А на утро уже было целых два варианта на ее основе: полноценное решение, и частичное. Второе - чтобы облегчить жизнь бизнесу, на случай, если проблема все же окажется нерешаемой. Как итог все выгорело, а мне в копилку упал новый ценный инструмент для решения такого класса задач. Как оказалось, проблема эта была ежегодная, и никто даже не рассчитывал что она решаема: ежегодно, несколько лет подряд, бизнес кидался ей в команды сеньоров, которые каждый раз разводили руками, потому что после первичного анализа выяснялось, что проблема фундаментальна, и классические решения с ней не работают. Я же просто прошел на шаг дальше в анализе, разобрался какой именно фактор обламывает классическое решение. А также решил попробовать исключить этот фактор из проблемы: просто отсек его, "вынес за скобки". В результате проблема схлопнулась до тривиальной. Тут то и стало понятно, что таким же образом можно решать и другие "нерешаемые" классическим образом проблемы. Идея простая, но разработчиков никто не учит, что можно просто сделать шаг в сторону и изменить саму проблему.
Согласен на все 73%!
В части разных стилей управления - на 100. Еще мой любимый Адзизес делил управленцев на PAEI (Решатель, Администратор, Предприниматель и Интегратор). Автор описал классическое столкновение менеджера-предпринимателя (придумал-сделал и похер как там потом, я звезда, я знаю, как правильно) и менеджера администратора (сделать то он сделал, а поддерживать это говно кто будет? А регламенты? А порядок разработки? А учесть все идеи или только автор гениален и олимпиадник?)
И да: объединение таких людей в одной команде дает классный эффект, я сам пробовал и Адзизес советует таких собирать под одной крышкой.
Если они вам не взорвут мозг и вы научитесь слушать их всех и делать лучшее, будет офигенный рост.
И конечно , я не согласен с крайне спорными тезисами что девопсы не нужны, что тестировщики хлам и блаблабла.
Автору надо бы просто попробовать построить дом метров на 350 или проект человек на 40 и на год длительностью. Вот тогда интересно будет почитать его мнение и про деплой и про автотесты. Пока что выглядит как максимализм человека, который серьезных проектов не видел.
Хабр прекрасен. Сделано программистами для программистов.
Существует 3 типа рабочих отношений:
Работа на результат. Человек-конец.
Процесс ради процесса. Человек-сосед.
Контроль процесса. Микроменеджер.
Люди разных типов не совместимы между собой, т.е. разный подход к работе двух людей ведёт к конфликтам, поэтому в команду надо нанимать людей с одинаковым отношением к работе.
Из статьи понял только что автор потрясающий супер-человек, но это не его вина, просто такая вот биология. Кстати у него всё получается и он потрясающий. Вот таким уж уродился, увы и ах. Паша дуров, илон маск и автор - люди из одного ряда. Ах да, что-то о быстро и дешево - ну, в общем, делайте криво и всё будет норм. Автору кстати вечный респект, он очень классный. Человек-Конец с большой буквы. Биология здесь выложилась на 100% качество.
Нет. Определение Человек-сосед не несёт негативной коннотации. Я много хватсался, но я весьма беспомощен часто, если б не жена(человек-сосед), то мне было бы гораздо хуже.
Зачастую мой талант состоит в том, чтоб найти человека соседа)
Я и не намекал на негатив в сторону человека-соседа. Здесь и не соревнование с победителем и проигравшим. Ну да, он переплатил, у него "крыша не накрыта", у него "окна будут искрить", он "проиграл в достижении цели". Но вот он таким вот вырос, вот такое у него мышление. Бывает, бывает.
У Вас же - мое почтение, восхищение и уважение. Вы очень крутой. Вы лучший из всех авторов хабра кого я читал. Прекрасный человек, программист, семьянин, планировщик и стартапер. Пойду поставлю вам плюс в карму и за коммент.
Это люди с хорошим системным мышлением и плохой памятью, они не любят долгие проекты, презирают нюансы и забывают имена. Поэтому они все упрощают и ускоряют. У меня квадратный в проекции дом с самой простой крышей, с минимальной длиной коммуникаций. Поэтому он теплый, надежный и дешевый.
Люди с другой стороны, аккуратные, любящие все по полочкам, документацию сделают это на порядок дороже, дольше и аккуратней. Их дом будет с флигелями. подогреваемой кровлей и умным домом. Но не будет достроен.
Очень сомнительные утверждения, которые полностью расходятся с тем, что лично я вижу в реальной жизни. Долгостроев по тетради в клеточку на порядок больше, чем долгостроев, которые начинались с хоть какой-то вменяемой рабочей документации. Я уже не говорю о том, что любые последующие модификации/ремонт долгостроев по тетради в клеточку - это игра в рулетку, когда нет никакого понимания, где, что и как именно было построено.
Ну и презирание нюансов - это тоже отличная заявка на получение лишнего геморроя через несколько лет после завершения строительства.
Очень хорошо у вас физиология языка интересная, трудно врубиться, зато почему-то гораздо чётче понимание, что хотел сказать.
В статье не хватает в конце деталей фундамента и стен и планов на будущее - т.е. простоит многомноголет или через 10 лет перекосит и проще снести чем выпрямить.
Какой 10 лет это уже долгострой и вообще очень долго. Автор утром построил, днем пожил, вечером уже другое строит, что там с этим домом уже не важно, результат то получен.
Обычный газобетон на ленте. И у меня и у соседа. Будут служить одинаковое еодичемтво времени. В обслуживании, мой проще и дешевле, хотя бы просто потому что он меньше.
У него больше точек отказа, хотя бы потому что у него штук 15 рукомойников, а у меня три, каждая розетка, каждая дверь, каждое окно может заскрипеть и заискрить, а у меня их сильно меньше.
очень хорошее уточнение, газобетон на ленте - недорогое и долговечное строение, и добавляет вашему тексту понимания. Так-то пол-года обычно негодный каркас на винтах. Ну и правильная электрика не искрит, правильный водопровод первые 50 лет не течёт, но это в итоге если сам делаешь.
Из-за того, что дом строился стремительно, он осел в первый год и передавил трубы водоснабжения. Всякое бывает.
Каркас я не стал строить , как раз потому чьо там нужно искать компетентных строителей, а газобетон любой таджик умеет класть, там сложно сильно на косячить.
Вот кстати да, все эти Илоны Маски так и делают. Там у них это даже культурологически нормальным считается - это мы сразу сарказм в комменте улавливаем.
Самое эффективное. что я встречал - пушить в дев
Автор, у тебя сколько людей в команде разработки было? Ты поддерживал написанный по твоему стилю проект несколько лети после первого релиза? а поддерживал проект написанный по твоим рекомендациям другими людьми 10 лет назад и когда в команде не осталось ни одного человека которые его начинали?
Сейчас у меня в команде 15 человек...когда я пришел в компанию, там вели разработку именно так...пушим в дев, никаких статусов... вобщем бардак...проект пилят уже 2 года вот я открываю код, вижу странное...открываю историю коммитов...а там...пи..ц там, у коммита одна подпись, то что в нем изменено совсем другое, задача на которую он ссылается закрыта (done да? один статус?) ...но как выяснилось она закрыта но не была resolved...но это не нужно же отмечать нигде? я три дня потратил чтобы найти концы как так произошло, что коммит типа с фиксом есть в логе гита, а исправления нет...
, я работал в окружении где около 200 человек ежедневно создают и пушат MR-ы в dev ветку, в CI/CD не останавливается даже ночью (потому что огромная очередь на мердж в прод), это настоящий живой проект, который работает до сих пор и развивается.
чтобы такое работало, нужен строгий регламент, чтобы любой чих в коде имел отражения в тасках, таски были в правильных статусов, чтобы ты мог дернуть джуна из соседнего отдела, и он сразу начал чтото делать не путаясь в чужих MR-ах
когда видишь список задач..и видно что есть таски которые Open-Work-Closed, а есть Open-Work-Resolved-Done, а есть Open-Work-Resolved-Closed --- это совершенно РАЗНЫН артефакты...
в первом случае задача открыта и закрыта - типа Not a bug или wont fix или double
во втором - открыто-поправлено-в продакшене
в третьем - открыто-поправлено-В ПРОД НЕ ПОПАЛО и ЗАКРЫТО (см комменты)
Если всё писать Open-Done то потом хрен поймёшь какая задача сделана а какая нет...будет свалка
Вы сейчас гордитесь тем, что с вашим проектом можно работать только используя сложные способы менеджмента и высококвалифицированных специалистов? И чуть что не так - сразу все развалится?
Ну ок. Мой проект делает то же самое только с джунами и без менеджеров.
Сделать с нуля ваш проект, чтоб он делал тоже самое - изи, легко.
Когда вы уже там нафигачили что-то, нахреновертили - а я должен все это починить? Смешно...
Нерешаемая задача:
- Вы человек-конец.
- Напишите компилятор.
Мой проект делает то же самое только с джунами и без менеджеров.
и что у вас за проект? магазинчик? чатбот? сервис заказа пиццы?
один проект который у меня был, это система электронного документооборота, масштабами как гуглдокс, где силами команды из 15 человек можно охватить только пару модулей из двух сотен...его как раз делало более 200 человек только бекендеров
второй проект это универсальный планировщик производства с четырьмя математическими моделями, из 10 человек на проекте только трое хотябы образно представляют как он работает целиком, потому что там сложность просто зашкаливающая...сам по себе код простой но бизнеслогика и внутренняя связность это просто нечто в плане осознания...еще в нагрузку... учитывая что предметную область знает только продуктовнер.
как вы думаете, можно силами херакхерак..в дев и впрод сразу, поддерживать такие проекты? тут даже когда всё понятно и разделено на части, разработчики не в полной мере понимают как будет работать их модуль в связке просто потому что это сложно
Ну ок. Мой проект делает то же самое только с джунами и без менеджеров.
Да, вот только код, написанный неопытными джунами код будет в лучшем случае кривым, а в худшем случае переусложнен, что в дальнейшем обязательно скажется на развитии проекта, потому что на добавление зависящих от этого кода фич уйдет больше времени = денег. Причем тут уже неважно, кто будет пилить эти новые фичи дальше: опытный сеньор или ровно тот же джун, потому что первому придется переписать хрень на нормальный код, а второй будет просто долго сидеть и тупить, понятия не имея, как же прикрутить к написанным ранее макаронам нужную бизнесу функцию.
Статья написана так, что складывается впечатление, что "все ..., а я Д'Артаньян". Конечно, я понимаю, что основной посыл в другом, но блин... Давайте смотреть объективно: действительно крупный и сложный проект с таким подходом не построишь. Как Вы привели пример со своим домом: он маленький. И пример с небоскребом и 500 мелкими домами. Это РАЗНЫЕ проекты вообще-то. Более того, они даже не являются альтернативами друг другу. Разве что по вместимости людей) Но даже так эта вместимость использует разную площадь, понимаете? Т.е. все равно приходится идти на компромиссы.
А если их нет и надо построить именно проект со множеством крупных фич, что подразумевает нехилую сложность? (Как уже говорили, привет финтеху.) Такая стратегия сломается, потому что при мало количестве людей в процессе что-то где-то в любом случае потеряется, факт потери не заметят, потом в последний момент очнутся и окажется, что все летит в тартарары, а времени уже не осталось и т.д. Не всегда все сводится к "проще - лучше", потому что незначительно усложнив систему в одном месте, можно очень сильно упростить ее в другом, ведь усложнением первый компонент сделали гибче, а в перспективе это даже приведет к куче плюшек.
Но в чем проблема-то? В том, что контекстное окно настолько велико, что маленькая команда из неподготовленных людей (привет снова примеру про джунов) просто не вытащит нагрузку и очень быстро забуксует. Когда контекстное окно велико, на его удержание приходится тратить дополнительные ресурсы = "накладные расходы". А ваш пример с бывшим твиттером и телегой лишь говорит о том, что в разных компаниях работают разные люди с разными способностями к оптимизации этих самых накладных расходов на поддержание процессов -- раз, и в разных компаниях плотность ответственности на человека тоже разная -- два. Вот и все.
Черт сними с небоскребами.
В чем по вашему разница, в том, что я дом достроил быстро, а сосед уже 6 год строит?
Представьте, что вы предприниматель и вам нужно проблему порешать. Хз. Столовку открыть для работников. Кого бы вы позвали?
Большая часть работы в айти не открытие столовок, а развитие макдональдсов
Удачи вам в пусть даже умеренном проекте на 2-3млн лок каждое утро поправлять коммиты в девелопе за сотнями программистов, которые фигачат без тестов и ревью и не поддерживают консистентный багтрекер
Сотни человек фигачащие в одну репу - уже звучит,как провал. Ту ваще пофиг, через мержреквесты или ещё как;то. Мержреквесты просто замедляют кодирование и смерть этого чудища. Без мержреквестов его просто добьют чуть быстрее)
Да бросьте. В мире миллион больших, долгосрочных и жизнеспособных проектов в монорепах.
Имманентную сложность невозможно выкинуть в окошко. Если вы делаете сложные вещи по-простому, то либо вы убиваете возможность развития, либо удобство сопровождения (тоже в конечном счёте возможность развития), либо перекладываете сложность на другой уровень, где вы её уже не видите, и с нею справляются без вас.
Ваши посконные рецепты хорошо звучат, когда кто-то вносит н е о п р а в д а н н у ю сложность в п р о с т о й проект, который к тому же не нужно долго развивать. Ну да, тут фигак-фигак в четыре руки и в продакшн - это работает, ни тебе тестов, ни проектных усложнений не нужно, трубу потом выпрямим ломом. Но такие проекты это сравнительно малая часть мира.
Кажется, Вы не поняли основной посыл моих слов.
Как по мне, ваш пример - плохая аналогия. Почему? Потому что все снова упирается в то же самое, что и с небоскребами: в 1) масштаб задачи и 2) требования к качеству ее выполнения (в частности, на какие компромиссы можно идти, а на какие -- нет). В случае со столовкой на мой дилетантский взгляд масштаб вроде не большой, а требования к качеству банальны, тут хватит и "джунов". Но когда вы захотите потом сделать из нее крутой навороченный ресторан, придут "сеньоры" и, скрипя зубами, переделают пол здания (условно), прежде чем преступят к основным работам, потому что надо будет исправлять косяки, которые ранее критичными не были. Если ресторан строить сразу, то и джунов звать не стоит: или не сделают, или сделают крайне хреново.
Оке. Вам сказали сделать столовку, вы пришли сделали треть ресторана с окнами в пол, и золотыми люстрами, деньги закончились, вы идете - просите ещё.
Денег нет, здравствуй it долгострой.
Ещё раз вам сказали сделать столовку. Вы сознательно усложнили проект, потому что подумали, что когда нибудь он вырастет в ресторан, в итоге делали столовку в 10 раз дольше и в 15 раз дороже.
Оно кому надо?
И второй момент, чем сложнее проект тем сложнее его апгрейдить. Всегда. Тем проще проект, тем проще в него встроиться.
Ах, да, еще кое-что забыл, но дополнить коммент до проверки не мог.
У "людей-соседей" есть маленькое, но важное преимущество: они реально шарят за свое дело. Вопрос не в том, что они знают, как делать, а в том, что они четко понимают, почему так надо делать. Они знают подводные камни, о которых "человек-конец" и не догадывается. Это еще одна причина, по которой тащить крупный проект "чел-конец" не сможет.
Итоги:
Сделать адекватно действительно большой проект "человек-конец" не сможет. В лучшем случае проект будет физическим воплощением слова "компромисс". Это одна крайность.
Да, "человек-сосед" откроет долгострой, но если он еще все же завершит, то это будет гибкий и качественный продукт. Это другая крайность.
Полностью согласен с тезисом статьи о том, что лучший вариант -- это тандем из этих двух. Потому что так можно будет сделать И быстро, И качественно, а все компромиссы, на которые пойдет команда, будут грамотными. Это грамотный баланс. Вывод: "человеку-концу" в большом проекте поддержка "соседа" нужна, как воздух. Подозреваю, именно поэтому вы 1) выбрали себе "человека-соседа" в качестве супруги, и 2) без ее поддержки вам было бы очень плохо, о чем вы упоминали в одном из комментариев выше.
Как раз к архитектуре соседей подпускать нельзя от слова совсем) Чем выше решение, тем меньше там соседей должно быть. У дома идеальная архитектура, квадратная с простой крышей, чётко выверенные нормы использования) Зачем он мне с ценными советами про 4 туалета?)
Но как исполнители они великолепны. Розеточки по линеечке, стены ровные, ламинат без зазоров. А наоборот тороплюсь всегда, всё тяп-ляп.
Вы не видите здесь противоречия? Вы же понимаете, что у вас и архитектура при таком подходе тяпляп? Да, возможно конкретно вам повезёт и вы не допустили критических косяков при строительстве, но куче других людей с таким подходом не повезет и дом пойдет под снос.
Не вижу. Вы с начала говорите про нюансы, а потом про крепкость фундамент - это по определению не нюанс, а очень важно. Да кое где розеток не хватает, ламинат разошёлся, но всё это чинится легко и быстро. Но мне лениво)
В чем проблема соседа? В том что херачит 400 метровый дом, при отсутсвии денег и сил, но зато у него марка входной двери в чертежах указана.
То есть про входную дверь подумал, а то что у него 30 лямов нет, он забыл. Соседи много думают про нюансы, концы наоборот умеют приоритезировать важное. Я когда строил дом даже не знал какая отделка внешняя будет кирпичом или деревом.
Это все работает только когда человек который отвечает за проект может полностью охватить все его аспекты, объяснить их разработчикам и еще уметь хорошо делегировать. Если чего-то нет, то получим то проект идеально работающий с точки зрения автора но делающий совсем не то что нужно заказчику, то чувака которые начинает самостоятельно писать в проекте все ключевые вещи, то человека от которого просто все пытаются сбежать. Помимо того что людей с подобным сочетанием качеств тупо мало, тут есть банально некий предел сложности когда один человек физически оказывается уже не в состоянии охватить настолько большой проект. Для самого себя что-то пилить с небольшой командой в подчинении (как в примере с постройкой дома или с Дуровым основывающим стартап) - это зачастую самое то, да. Но вширь оно масштабируется плохо.
Из содержательного посыла статьи я бы выделил один простой тезис: не надо переусложнять вещи без нужды. Если простые решения работают и решают проблему то не надо городить огород со сложными просто потому что "все так делают" или "на будущее". Человек-результат нередко (но не всегда!) неплохо умеет находить простые решения и следовать им, и в этом одно из его основных достоинств. Просто следует понимать что это не серебряная пуля и простые решения работают не везде и не всегда.
в ширь масштабируется плохо ...
если серьезно, масштабируется плохо все что делается ради материальной выгоды, что-то сделать можно, типа как на конвейере у Форда стандартные операции, или sw эквивалент, но это трудно делать с высоким качеством, и что главное не приносит удовлетворения, а вот сгореть вполне можно,
т.е. для массового производства ширпотреба материальная выгода работает, в том числе в области sw, но заниматься этим для творческого человека трудно,
к google и прочим FAANG, вполне относится, насчет Маска возможно нет, вероятно он не ради денег, уже вполне достаточно на любой вкус
ps
вывод простой - для масштабирования нужна общая идея
Я хотел сказать, что некоторые(особенно те люди которые любят процесс) физиологически не умеют не переусложнять.
Представьте тебе всегда хотелось ЭластикСерч или ИИ на проме попробовать. Ты его сунешь туда при первой возможности, нужен он там или нет.
А другой человек наоборот ИИ не любит, а хочет побыстрей чтоб заработало. Он максимально все упростит и по выкидывает, оставив только то, что реально нужно.
...и на каждую новую хотелку заказчика делает костыль, потому что альтернатива - дикие трудозатраты, "мы делали просто и такого не закладывали, надо переделать"
На двадцатом костыле проект становится принципиально неподдерживаемым и сдается в утиль. Поэтому и называется такой человек: человек-конец.
Вы всерьёз думаете что приделать что-то к простому проекту, сложнее чем к сложному?
Как раз у таких как я нет костылей, там всё примитивно. А у вас ещё первую фичу хрен знает как прикрутить, потому что там всё кабздец как понимать и проще костылём прикрутить, чем понять что вы имели в виду.
В итоге у вас есть коннектор для подключения, но его не нашли в груде других усложнений и рядом на саморезы прикрутились.
Вы всерьёз думаете что приделать что-то к простому проекту, сложнее чем к сложному?
Да порой просто невозможно без переделки всей проделанной работы
Давайте представим себе игрушечный пример: коллекция и итератор. Вы, как простой человек, не будете делать итераторы, это глупое усложнение, и сделаете, ну я не знаю, массив с индексами. Просто, надёжно, как молоток!
Потом пришли новые требования, коллекцию пришлось заменить на другую, в которой нет индексов, и кто-то бегает и за вами подтирает в пятистах местах.
(пример радикальный и условный)
Массив сложнее, чем итератор)
И первый вопрос, который я задам - "зачем." Какого чёрта ты ваще лезешь в код, тебя это трахать не должно. У тебя медленно? Жалуйся? Данные не те? Жалуйся! А как я это реализовал тебя трахать не должно.
А давайте реальный пример? Настоящий вот когда проект с повышенной сложностью было легче переделать. Ни разу за 10 лет у меня такого не было! Вот случай когда ты разгребаешься в кучах кодах на будущее - это вот каждый день. А такого, чтоб ах как хорошо, что предусмотрено - такого никогда не было)
Кому жалуйся? Вы написали этот код пять лет назад и давно работаете в другой организации. Жаловаться некому, остаётся молиться.
"А как я это реализовал тебя трахать не должно." - вот и ответ на все сомнения, собственно, спасибо. Нормальный подход для пет-проекта с жизненным циклом в пару месяцев, в принципе.
Пока читал статью как-будто все больше и больше убеждался, что читаю откровенную провокацию и, судя по комментам, цель достигнута. В противном случае в сухом остатке можно увидеть тьму выпадов, основанных на том "что итак все знают" или на репутации автора (в совокупности получается больше необоснованные выпады). И вроде с некоторыми пунктами можно согласиться, но в целом статья получается суматошная, спорная и, к сожалению, опечаточная (хотя возможно это была практическая демонстрация ненависти к нюансам автора ;) )
прочтя статью, почему-то вспомнилось фамусовское "собрать бы книги все да сжечь"
мне кажется есть люди умные и трудолюбивые, соответственно это дает четыре квадранта
Все, что я напишу дальше - не для того, чтобы оскорбить Вас или назвать вас глупым и уж точно не для того, чтобы раскритиковать статью, хорошая статья. Вы просто ошибаетесь. А ошибаетесь Вы, т.к. думаете "с высоты своего роста". Во-первых, и в главных - у всех своя цель. И она есть у каждого. Не у всех она ясная и понятная, но она есть. Цель может быть заключена в конечном результате, а может в самом процессе достижения любого результата.
Сосед не пошел на Фудзияму, потому что чего-то там не хватало, как он вам сказал. И вы это приняли за такой болезненный процесс планирования в голове у соседа, т.к. вы сами так делаете - составляете или даже сразу видите у себя в голове четкий план "что, как, куда" и попер. А сосед вам просто мог сказать первое, что ему в голову пришло. Вполне вероятно, что ему вообще эта Фудзияма и тем более подъем на нее нафиг не сдались. А признаться напрямую олимпиадникам в этом бывает сложно - засмеют.
Сосед сказал, что квартиру не может из-за итальянского унитаза отремонтировать? Да у него миллион других причин на это может быть, но это не вашего ума дело, поэтому он опять говорит вам первое, что пришло в голову.
Про проекты-долгострои. Можно одним коротким предложением-вопросом. Как вы объясните заказчику, зачем ему тратить охулиард денег на проект, который вот такой умник может за 2 недели на коленке состряпать?
Как тут уже кто-то писал вам - не обобщайте. Самое большое заблуждение - это из частного делать общие выводы.
А вообще, вы очень важный вопрос поднимаете. Все эти аджайлы, херайлы, митапы, стартапы уже вот здесь сидят. И дело не в том, что аджайл - это болото. На самом деле, при правильном применении он очень работоспособен и хорош. А в том, что принцип и сферы применения этого аджайла мало, кто понимает. В итоге получаем то же болото усложненное непонятными терминами и длинными бесполезными совещаниями. Есть много хороших коммерческих предприятий, которые очень слаженно работают по аджайлу совершенно не подозревая о существовании этого слова. Просто там адекватная команда подобралась, которая не будет "красить машину перед сваркой швов".
А где вы меня оскорбили? Вы всё повторили, что я сказал другими словами. Да хотите быть богатыми, делайте как сосед за дохренилиард денег и у вас будут конфы в Лондоне и дачка на Бали.
Да у соседа миллион причин, чтоб не закончить и мне всё равно какие. Главная причина одна, он сосед и всегда найдёт причину не закончить. Не будет унитаза - будет ещё чро нить, главное, что его не тяготит эта ситуация, его всё устраивает.
Дуров, когда ему понадобился логотип для «Вконтакте» просто написал в текстовом редакторе две синих буквы шрифтом Ариал. Он не устраивал тендер, не нанимал дизайнера, он потратил 2 секунды времени и 0 денег. Это пример того как мыслят люди‑концы и почему они достигают успеха.
Дык там же вроде Лебедев, при всей моей к нему ненависти, рассказывал, что ему Дуров заказывал фирменный стиль Контакта и когда ему выкатили 100500 вариантов он все перечеркнул и нарисовал свои две буквы упомянутым шрифтом и цветом.
Опыт, сын ошибок трудных ...
Первый мой опыт самостоятельного программирования случился на PHP, причем по образованию я экономист и разработка в мои задачи не входила. За два месяца на PHP я написал "Почтовый робот", который сначала умел отправить счета и счета фактуры на электронную почту (сформировать список, сгенерировать pdf, отправить в N потоков, обработать ошибки). Там сразу был запуск по расписанию с фильтрами, многопоточность, отчеты. Чуть позже добавились варианты разных рассылок по емаил, рассылка СМС, автообзвон по телефону, отправка оператору ЭДО и даже тревога по температуре в серверной.
Позже решили сделать по правильно, я все что сделано описал в ТЗ и подрядчик делал это 1,5 года пока пришли примерно к такому же результату.
Потом я работал, работал (пару раз сменил работу) и сейчас вспомнить страшно тот "говнокод" на PHP, который возможно там до сих пор работает.
И я уверен, что в 99% случаев если "пушить в девелоп", то результатом в итоге будет именно "говнокод".
Ходить "в упрощение", "в усложнение" или "в систематизацию" - зависит не от физиологии, а от задачи и её контекста.
Примеры из жизни инженера-конструктора:
В упрощение: На 85% заменил массовое изделие стоимостью ~5К рублей гнутой металлической пластиной ценой буквально в пачку сигарет. Заняло пару часов времени на разработку. (кто после этого скажет что олимпиадные задачи не нужны - тот не прав). Потом "чтоб два раза не вставать" за день сделал рефактор после "человека-соседа" и ужал ценник оставшихся 15% исходника до 1,5К.
В усложнение без масшабирования: Ради улучшения характеристик одного мелкосерийного изделия применил три ранее не использовавшихся на предприятии технологии/решения. Надо было сделать конкретно этот продукт лучше всех конкурентов любой ценой - сделал.
В систематизацию: Заменил класс устройств на одну модульную систему, которая собирается почти как Лего. Раньше "люди-концы" прибегали и просили за два-три месяца успеть разработать и изготовить новую монолитную "игрушку", как в прошлый раз, но с перламутровыми пуговицами. Теперь довольные сидят на куче "кубиков", сами что им там надо собирают, изредка требуя новый "кубик" сроком разработки в два дня и изготовления в неделю.
Это на уровне рядового разработчика. ИМХО на уровне руководителя всё должно быть ещё более гибко и продумано.
А мне как раз не хватает упрощения в работе в юридической сфере. Иногда такие сложные системы учёта и движения дел нагораживаю) Да и в жизни аналогично.
Вы сделали ошибочное допущение, что условный "недострой", это абстрактный человек-сосед. А вы не думали, что вероятно, это человек-конец, который в этот раз не смог? А человек-сосед таки довёл свой дом до успешного завершения проекта и все у него хорошо? Почему вы решили, что человек конец, это человек результат или человек успех? С описано вами подходом риски любого проекта радикально возрастаю, да, если прокатит, то получится быстро и дёшево, но раз риски возрастают, то и не прокатит будет сильно больше. Если переводить на стройку, вот строили без проекта, а завтра у фундамента угол на 20см ушёл, или оказалось, что газовая служба в безпроекте котел теперь её согласовывает, посмотрите строительные каналы, сколько таких домов тяпляп которые теперь только в утиль.
Задача, не в том чтоб обвинить меня в тупости. Дайте своё объяснение почему Дуров командой в 30 человек делает тоже самое что Твиттер командой в 6к человек.
Бородатое вспомнилось:
Менеджер пришёл к Учителю и показал ему требования на новое приложение. Менеджер спросил Учителя: “Сколько потребуется времени для разработки этой системы, если я назначу на неё пять программистов?”
“Один год”, — ответил Учитель.
“Но эта система нужна нам как можно скорее! Сколько потребуется времени, если я назначу десять программистов?”
Учитель нахмурился. “В этом случае потребуется два года.”
“А если назначу сотню программистов?”
Учитель пожал плечами. “Тогда разработка никогда не закончится”, — сказал он.
Я никоим образом не пытаюсь вас обвинить в тупости.
По моему мнению вы делает очень много допущений которые ничем не обосновываете, от сюда и вопросы. Например этот ваш комментарий, "Дуров командой в 30 человек делает тоже самое что Твиттер командой в 6к человек.", что дает вам основание предполагать, даже если размеры команд вами указаны достоверно, что они делает тоже самое, какие именно показатели позволяют сделать такое заявление?
Например выручка данных компании отличается радикально, доходность также, аудитория, по этому показателю мне сложно судить, но думаю она тоже имеет существенную разницу. Что именно вы сравнили, чтобы сделать такое заключение, делают тоже самое, мне кажется ваша оценка взята с потолка на основании субъективного ощущения одной и сторон продукта.
И кстати, я смотрел ютубчик. Внезапно, когда показывают ляпы строительства там не ляпы, а полная кабзда, уровня "вообще не положили арматуру в фундамент". Из чего делается вывод,что нужен высоскокыалифицированный инженер. Нет блин, достаточно базового ютуба, чтоб знать что нужно арматуру кидать ы фундвмент. Или показывают лопнувшее перерытие, а там зал 12*12 метров, без единого столба и проекта нет.
Да, когда ты херачишь консольный балкон с вылетом 6 метров без опор, расчёт и проект нужен. Когда у тебя максимальная ширина комнаты 4 метра, то нафиг не нужен.
И проблема не в том что я плохо делаю, хорошо делаю. Проблема, в том когда тебе сказали дачку сделать,а ты херачишь монолитную плиту толщиной три метра в фундамент, которая прямое попадание главным калибром линкора Ямато держит, в надежде что потом вместо дачки ты тут небоскрёб будешь делать
Первая статья, которая заставила меня зарегистрироваться на хабре, ибо появилось желание вставить свои 5 копеек и очень важное имхо.
Да, я человек-конец. Да, я видел, вижу, щупаю, делаю большие проекты, команды по 40+ человек и команд много и проектов много.
Спасибо Автору. Сперва подумал "ода самому себе" а потом как понял....
Да, наверху должны стоять люди-концы. Сейчас пришел в команду, где самый БИГ Босс человек-сосед и топ-менеджмент его люди-соседи. И это ад, товарищи. Чем выше сидит руководитель, тем меньше он может знать "а как там внизу", но он должен знать и понимать суть.
Автор верно отметил, что человек-конец должен работать в связке с человеком-соседом, ибо только в споре рождается истина.
Имхо, все кто не согласен по большей части крутые специалисты, но не менеджеры. А это два абсолютно разных психологических типа. Человек-конец - должен быть менеджером (продакт овнером) а человек-сосед - это специалист (например, СТО).
На подумать: тут столовку приводили в пример с апдейтом в ресторан. Встречный вопрос: А как так вышло, что из столовой надо сделать ресторан? получается гипотеза на входе была - фигня. Значит корень бед не там ищите, господа.
А если вдруг и возникла потребность снести все и сделать заново - нормальное дело. Потому что в изначальной гипотезе такого условия не было.
Тезис - "сеньоры придут и будут мучаться перепиливать ваше Г, которое решало вообще другую задачу" даже смотрится странно.
Лет 10 назад работал в области заказной разработки софта. Там проекты были по ТЗ договору в формате «сделал и забыл». В рамках этого ТЗ я делал минимально необходимую хрень, чтобы покрыть требования. У меня получались простые проекты, меня не парило что будет дальше. Разработка шла как по маслу. Быстро и просто. Оптимальный путь в рамках ТЗ. Тесты? Зачем? Один раз сделали, сдали и забыли. Бонусом само ТЗ шло как документация. Короче я был человеком-концом.
Сейчас я работаю в небольшой продуктовой компании. На протяжении двух-трех лет я по аджаилу делал минимально необходимую хрень. Каждый спринт подвозили новые ништяки. И однажды оно стало ломаться. А существующие клиенты - ругаться. Тестов же не было. Понадобились тесты. Документация в тасках в жире. Пойди собери ее конечный вариант из мелких изменений. Чтобы объяснить клиентам и техподдержке КАК оно должно работать. Стали оформлять документацию. Сначала пользовательскую, сейчас вот внутреннюю. Раньше я деполил сразу в прод. А сейчас мы тюним процессы. И я стал превращаться в человека-соседа.
После того как я превратился в человека-соседа - я стал думать о будущем, ну что если завтра придет толстый клиент? Мои решения стали более тяжеловесными. Но такое не укладывается в спринт. Поэтому отложим. Через месяц, два, три - все равно приходил новый толстый клиент и все ломалось. И все равно опять все половина переписывалось. Но теперь меня еще спрашивают «долго че то, надо еще вчера было сделать»
И вот теперь я нахожусь здесь. Есть ответ на вопрос что делать дальше? Ни человек сосед, ни человек конец не осиливают текущую ситуацию.
Про тесты у меня нет исследования, но есть кейс из практики. Один заказчик захотел развесистую систему скидок; итоговый результат зависел региона покупателя и групп лояльности, куда покупатель входил. При этом внятно изложить свои мысли заказчик не мог.
Тогда мы составили ему табличку в экселе, в которой были расписаны все комбинации групп лояльности и регионов, указан %скидки по каждому параметру и попросили заполнить, какой будет итоговая скидка в каждом случае. Заказчик сделал.
Мы эту табличку переписали в виде тестов и постепенно шли к тому, чтобы все тесты стали зелёными. Где-то ближе к концу пути в коде была сделана оптимизация, понятная и логичная. Вот только после неё уже пройденная часть тестов внезапно завалилась.
Был там какой-то нюанс, про который на старте помнили, а потом забыли и при рефакторинге потеряли.
Как затащить быстро и дешево