но все что я говорил — касается «штатного поведения»
правило «тормозной путь со скорости Х км/ч составит У м, на скользкой дороге — У*1.3 м» — подходит в большинстве случаев.
но если мне нужно во чтобы то ни стало уметь со скорости 100 км/ч остановиться через 25 метров, тогда я полезу под капот и буду очень тщательно изучать тормозную систему, подбирать колодки, тормозные диски и проч.
Давайте забудем о том, что на дороге вокруг нас много идиотов машин. Я ведь не пишу свою программу с оглядкой на то, как кто-то другой пишет свою :) Упростим систему до «я и мой автомобиль».
Интерфейс здесь является постоянным — педали, руль (опционально — ручка КПП). В конечном итоге грамотное владение интерфейсом позволяет мне доехать из пункта А в пункт Б, а вовсе не знание устройства автомобиля. Какие именно стоят тормозные колодки, когда я торможу (в штатной ситуации!), не играет роли. Лишь бы они вообще были :) Но и это уже лишние подробности реализации. «Жму педаль — торможу», это главное. А колодки там или парашют — не важно.
Если мне надо куда-то поехать — я сажусь в автомобиль и еду.
Жму газ — он разгоняется, томоз — тормозит, кручу руль — он поворачивает.
Пока все это происходит — мне все равно, что у него там внутри. Вот честно.
Дизель там или бензин, инжектор или карбюратор — зачем мне это знать?
Ну что-то я знаю, конечно. Омывайку там залить, колеса подкачать :)
Но это необходимый мне минимум.
Начинаются проблемы посерьезнее — я не лезу под капот, а везу его на сервис.
Где знающие люди его починят. А я пока буду заниматься тем, что мне интересно. И ездить при этом на метро, да.
Просто перечислить весь стек технологий, с которым я работаю каждый день, займет полэкрана.
В тонкости каждого фреймворка не вникнешь, жизни не хватит.
программисты — лирики, они не хотят планировать, они хотят весело программировать, пробуя прикольные фичи, новые фреймворки, на каждом углу рассказывая, что им для работы нужно вдохновение и «печеньки». Продолжая аналогию с шахматами — «они же умеют играть» (С) и поэтому им скучно играть похожие партии. Они могут «для лулзов» взять и пожертвовать пару пешек. Или ферзя. Или могут бесконечно выстраивать фигуры на доске красивыми рядами, называя это «рефакторингом» или «реализацией паттерна». И очень редко задаются вопросом — «А кто оплачивает банкет?» (С)
А оплачивают его серьезные дяди, которые прежде всего считают деньги и время. И им дела нет до веселых программистов, им надо знать «когда?». И они постоянно задают этот вопрос физику-ПМу. И ответ «месяца через два» или даже «скоро» их не устраивает. Им нужны цифры и проценты. Поэтому ПМ и рисует планы, схемы и графики. Переводя вдохновение программистов в скупой язык цифр. И дяди дают программистам новую банку варенья и коробку печенья.
А если не будет никакого плана — то будет не работа и результат, а анархия, все весело проведут время, завалят проект и дружно пойдут искать новую работу.
Последний проект: ЭДО для сети гипермаркетов. Начало — декабрь, плановое окончание — апрель, срок определен бизнесом — под начало договорной кампании. Начальной оценки как таковой не было, делали на основе расплывчатого ТЗ с постоянными уточнениями по ходу дела. Прототип показали в середине февраля. Сдали первую версию в мае и сразу стали делать вторую.
Вторую версию оценивали тимлид + пара ведущих программистов на основе имеющейся кодовой базы, формальные методики не использовались, расписали на 2 части, конечный срок был определён ноябрем. В основе переделок — редактирование Экселя через вебдав. С этим было очень много проблем, технических и постановочных, поэтому первую часть сдали в марте, а вторую — только в августе.
Но есть небольшое дополнение. «ПМ — бывший программист» — это хорошо для оценки. Но у ПМа ещё куча всяких обязанностей. Для которых «бывший программист» может абсолютно не подходить. Подробности хорошо описаны в книжке «Как пасти котов».
«ПМ достаточной квалификации» — кто это, если не «бывший программист»? Иначе его «оценка» будет просто высосана из пальца продиктована чем угодно, только не реальной действительностью.
Если ПМ не из «бывших», то он спрашивает реальную оценку у тимлида. А потом уже её «согласовывает» по инстанциям. Желательно в интересах команды.
"Тут вообще нечего обсуждать, производительность должна быть константой, основная задача руководителя – следить за этим"
И в чем же мерять эту самую «производительность»? Лучшие умы годами бьются над этим, изобретают всевозможные метрики, а воз и ныне там. Проблема разработки ПО как «инженерной науки» как раз и состоит в том, что тут нет прямого аналога «скорость * время = расстояние». Токарь третьего разряда выточит штуцер за час, а второго — за полтора. А что является «штуцером» для программиста? Сортировка пузырьком? Но никому не нужны 1000 одинаковых процедур сортировки (в отличие от 1000 штуцеров). Каждая строчка каждого программиста — уникальна (даже копи-паста не помогает, а вредит). И каждая система в конечном итоге уникальна, пусть даже многие из них называются похоже.
Перед началом стройки мы можем представить себе мост, или здание, спроектировать его с хорошей точностью, разбить на узлы, посчитать кол-во кирпича, песка и ж/б свай и получить примерную смету по времени и цене. А кто может себе с подобной детализацией представить программный продукт до начала его разработки? Тут я прежде всего говорю не о функциональности, а о собственно создаваемом программистами артефакте — программном коде. Сколько там будет строк, классов, этих самых функциональных точек?
«Проклятая неизвестность». Перед которой пасуют все методики.
Поэтому мы нанимаем опытных программистов — и всё равно идем по большей части наугад, постоянно корректируя начальную оценку.
вообще я считаю, что в любой книге можно найти что-то полезное.
причем — даже не в первом прочтении.
второй, третий раз читаешь — ещё что-то новое, какое-то другое понимание.
плюс разные книги на смежные темы дают более полную картину.
Эх, все это замечательно, но всю малину обычно портит вопрос, который тебе задают в самом начале: «За сколько времени вы это сделаете и какими ресурсами?»
Очень сомневаюсь, что у господина Каца Марца изначально имелся на него ответ. Хоть сколько-нибудь достоверный.
Есть такая поговорка, что классный бильярдист не делает сложных ударов. Все его удары довольно простые. Но конечно тут есть определенная доля лукавства, потому что, чтобы следующий удар был простой — нужен хороший «выход битка» после предыдущего удара. В этом собственно и заключается сложность бильярда, не в «кладке», а в «выходе» и построении серии.
Так и в программировании — джедаем нужно быть не для того, чтобы «решать сложные случаи», а для того, чтобы предвидеть и избегать их, выбирая простые и эффективные способы решения задач.
Мы делали документооборот для сети гипермаркетов с филиалами по всей стране. Ни на какой анализ время никто не выделял, экономили на всем, велено было сделать на опен-сорс продуктах за полгода, ибо «в апреле начало годовой договорной кампании». Сделали к маю.
Им не нужно открывать исследовательскую лабораторию, им деньги надо зарабатывать.
Тут вкралась неточность. Деньги платят все-таки НЕ за «говнокод и костыли», а за «хорошую систему». Просто заказчик редко понимает, что же именно он получил. И даже если понимает — деньги-то уже потрачены.
правило «тормозной путь со скорости Х км/ч составит У м, на скользкой дороге — У*1.3 м» — подходит в большинстве случаев.
но если мне нужно во чтобы то ни стало уметь со скорости 100 км/ч остановиться через 25 метров, тогда я полезу под капот и буду очень тщательно изучать тормозную систему, подбирать колодки, тормозные диски и проч.
Давайте забудем о том, что на дороге вокруг нас много
идиотовмашин. Я ведь не пишу свою программу с оглядкой на то, как кто-то другой пишет свою :) Упростим систему до «я и мой автомобиль».Интерфейс здесь является постоянным — педали, руль (опционально — ручка КПП). В конечном итоге грамотное владение интерфейсом позволяет мне доехать из пункта А в пункт Б, а вовсе не знание устройства автомобиля. Какие именно стоят тормозные колодки, когда я торможу (в штатной ситуации!), не играет роли. Лишь бы они вообще были :) Но и это уже лишние подробности реализации. «Жму педаль — торможу», это главное. А колодки там или парашют — не важно.
Имхо прогресс в том и состоит, чтобы человечество в основной массе пользовалось плодами предыдущих поколений, а не изобретало колесо каждые 20 лет.
Жму газ — он разгоняется, томоз — тормозит, кручу руль — он поворачивает.
Пока все это происходит — мне все равно, что у него там внутри. Вот честно.
Дизель там или бензин, инжектор или карбюратор — зачем мне это знать?
Ну что-то я знаю, конечно. Омывайку там залить, колеса подкачать :)
Но это необходимый мне минимум.
Начинаются проблемы посерьезнее — я не лезу под капот, а везу его на сервис.
Где знающие люди его починят. А я пока буду заниматься тем, что мне интересно. И ездить при этом на метро, да.
Просто перечислить весь стек технологий, с которым я работаю каждый день, займет полэкрана.
В тонкости каждого фреймворка не вникнешь, жизни не хватит.
программисты — лирики, они не хотят планировать, они хотят весело программировать, пробуя прикольные фичи, новые фреймворки, на каждом углу рассказывая, что им для работы нужно вдохновение и «печеньки». Продолжая аналогию с шахматами — «они же умеют играть» (С) и поэтому им скучно играть похожие партии. Они могут «для лулзов» взять и пожертвовать пару пешек. Или ферзя. Или могут бесконечно выстраивать фигуры на доске красивыми рядами, называя это «рефакторингом» или «реализацией паттерна». И очень редко задаются вопросом — «А кто оплачивает банкет?» (С)
А оплачивают его серьезные дяди, которые прежде всего считают деньги и время. И им дела нет до веселых программистов, им надо знать «когда?». И они постоянно задают этот вопрос физику-ПМу. И ответ «месяца через два» или даже «скоро» их не устраивает. Им нужны цифры и проценты. Поэтому ПМ и рисует планы, схемы и графики. Переводя вдохновение программистов в скупой язык цифр. И дяди дают программистам новую банку варенья и коробку печенья.
А если не будет никакого плана — то будет не работа и результат, а анархия, все весело проведут время, завалят проект и дружно пойдут искать новую работу.
Вторую версию оценивали тимлид + пара ведущих программистов на основе имеющейся кодовой базы, формальные методики не использовались, расписали на 2 части, конечный срок был определён ноябрем. В основе переделок — редактирование Экселя через вебдав. С этим было очень много проблем, технических и постановочных, поэтому первую часть сдали в марте, а вторую — только в августе.
Но есть небольшое дополнение. «ПМ — бывший программист» — это хорошо для оценки. Но у ПМа ещё куча всяких обязанностей. Для которых «бывший программист» может абсолютно не подходить. Подробности хорошо описаны в книжке «Как пасти котов».
просто высосана из пальцапродиктована чем угодно, только не реальной действительностью.Если ПМ не из «бывших», то он спрашивает реальную оценку у тимлида. А потом уже её «согласовывает» по инстанциям. Желательно в интересах команды.
И в чем же мерять эту самую «производительность»? Лучшие умы годами бьются над этим, изобретают всевозможные метрики, а воз и ныне там. Проблема разработки ПО как «инженерной науки» как раз и состоит в том, что тут нет прямого аналога «скорость * время = расстояние». Токарь третьего разряда выточит штуцер за час, а второго — за полтора. А что является «штуцером» для программиста? Сортировка пузырьком? Но никому не нужны 1000 одинаковых процедур сортировки (в отличие от 1000 штуцеров). Каждая строчка каждого программиста — уникальна (даже копи-паста не помогает, а вредит). И каждая система в конечном итоге уникальна, пусть даже многие из них называются похоже.
Перед началом стройки мы можем представить себе мост, или здание, спроектировать его с хорошей точностью, разбить на узлы, посчитать кол-во кирпича, песка и ж/б свай и получить примерную смету по времени и цене. А кто может себе с подобной детализацией представить программный продукт до начала его разработки? Тут я прежде всего говорю не о функциональности, а о собственно создаваемом программистами артефакте — программном коде. Сколько там будет строк, классов, этих самых функциональных точек?
«Проклятая неизвестность». Перед которой пасуют все методики.
Поэтому мы нанимаем опытных программистов — и всё равно идем по большей части наугад, постоянно корректируя начальную оценку.
«наличный рассчет» — должно быть «наличный расчёт»
«базналичный рассчет» — должно быть «безналичный расчёт»
вообще я считаю, что в любой книге можно найти что-то полезное.
причем — даже не в первом прочтении.
второй, третий раз читаешь — ещё что-то новое, какое-то другое понимание.
плюс разные книги на смежные темы дают более полную картину.
Очень сомневаюсь, что у господина
КацаМарца изначально имелся на него ответ. Хоть сколько-нибудь достоверный.Так и в программировании — джедаем нужно быть не для того, чтобы «решать сложные случаи», а для того, чтобы предвидеть и избегать их, выбирая простые и эффективные способы решения задач.
Это был псто в защиту Хибернейта :)
Им не нужно открывать исследовательскую лабораторию, им деньги надо зарабатывать.