"Приблизительно ворочать мешки" и "ворочать мешки" - это две большие разницы. Именно здесь чаще всего и возникают недопонимания между заказчиками, которые же приблизительно точно знают чего хотят - и программистами, которые должны уже однозначно точно дать указания компьютеру что он должен делать : ) Впрочем, это лирика. А насчет долженствований - да я просто хотел узнать как именно должна работать ваша идея, ибо в своем приблизительном виде она выглядит для меня наивной по озвученной мной и некоторыми другими участниками нашей беседы причинам. Поэтому надо смотреть "конкретный код", а не оперировать очередными неопределенностями - такая у нас работа.
Как минимум тогда интересно - каким образом вебстриминг, например, и банковская система является типовой относительно друг друга? Вы хотите сказать, что банковские расчеты и логика - это такой вид вебстриминга?
Вы так считаете? На мой взгляд, большинство задач в МИРЕ это у нас есть какие‑то данные, нужно взять типовые инструменты, сделать типовую аналитику с типовым фронтов и с типовым беком, сделать интеграцию типовыми способами и т. д.
Невероятно сильное обобщение. В принципе, все в природе из одних и тех же атомов состоит - значит ли это, что разница между камнем, положим, и человеком - невелика? : )
А я еще раз повторю - чтобы говорить об искажениях оценки надо знать для начала - какая оценка эталонная : ) А когда неизвестно что есть Истина - нельзя сказать и что есть Ложь.
А с чем выплаты связаны? Какова функция расчета раз уж мы тут все такие программисты - нам нужна функция - что на входе и как рассчитывается результат этой функции : ))) А так - это напоминает старинный мем:
Ну да, для типовой разработки это более-менее работает - вот вы пишите типовые конфигурации 1С, к примеру, имеете штат сотрудников, чьи навыки работы с типовыми инструментами 1С экзаменуете периодически - и да, можете вполне адекватно предсказывать разработку. Но это очень далеко не всё, что происходит в разработке ПО - как раз таки подавляющее большинство - это новые предметные области с новыми подходами и новыми требованиями - и здесь, в этой обширнейшей нише расчеты сроков становятся заметно неточными, потому что нет типовых решений.
Вам же объяснили уже, что в большой системе - нелинейные зависимости между входящими данными и результатом. Так же точно происходит с предсказанием погоды - это же уже исследовалось, и даже понятно почему так происходит - погуглите Эдварда Лоренца с его "эффектом бабочки".
Тут вовсе не рассматривается вопрос стимуляции разработчиков, тут именно что вопрос - а как оценить разработку проекта более-менее приемлемо? Эта проблема не только перед заказчиком стоит, но и перед разработчиком.
Усреднение разных оценок не поможет. Разработчики все с разным опытом, да и опыт одного и того же разработчика изменяется со временем. Это раз. Второе - это то, что любая оценка даже опытнейшего разработчика строится на неопределенности - ну то есть в лучшем случае понимает это, а в худшем - занимается самообманом, который выльется в срыв озвученных сроков, что повсеместно и происходит с малоопытными, но - или, скорее - "потому и" - уверенных в своих оценках, специалистами.
Конечно, бывают проекты, в которых требования достаточно точны и даже имеется опыт их реализации - их оценивать легче и можно не перезакладываться сильно на риск, но даже в таких проектах факторы неверных толкований и вероятных изменений не отменяются и создают риск не влезть в неучитывающий их срок.
Конечно, если вы пишите из года в год примерно одно и то же на типовой платформе, плюс как-то научились контролировать грейд специалистов (обязательной сертификацией/аттестацией, например), то статистический подход еще может помочь, но это довольно узкая область разработки ПО. Подавляющее же число разработок ПО слабо походят на друг друга.
И в любом случае, это про те случаи, когда проект небольшой, по большей части состоит из знакомого по опыту функционала и требования прописаны достаточно детально, а часто - ТЗ состоит из дефиниций "хотелок", без каких-либо деталей и/или требуется "запилить" что-нибудь из разряда "как у Гугла" - только вот заказчик не понимает, что Гугл разрабатывал свою машинерию 30 лет огромными командами и сделал кучу неудачных подходов, прежде чем получил результат.
Проблема в том, что даже в адекватно прописанном в ТЗ и знакомом по опыту функционале всегда остается много неопределенности, если даже вам вдоль и поперек знакома фича по предыдущему опыту - это вовсе не означает что вы:
Точно идентифицировали фичу - вполне может быть, что заказчик подразумевает нечто иное.
Фичи практически никогда не бывают одинаковыми - иначе, как и было подмечено, разработчики бы тупо собирали ПО из давно сделанных кирпичиков - но нет, каждый раз свои нюансы.
Практически ни один проект не обходится без внесения изменений в процессе разработки - как бы там ни божился заказчик и как бы опытен ни был аналитик/архитектор.
Из известных мне и более-менее рабочих способов гадания на сроки - это закладка риска: то есть определяешь сколько по твоему мнению на разработку фичи нужно времени и добавляешь на неопределенность еще 15-20% времени - как раз на то, что фичу неправильно понял, фича будет меняться и/или возникнут другие непредвиденные обстоятельства.
В целом это работает, но не в минимум двух случаях:
Нет опыта реализации подобного - соответственно не от чего отталкиваться. Частично решается тем, что проводишь экспресс изучение темы - хотя бы где и что надо узнать из технологий и сколько времени уйдет на уже изучение исходя из объема материала - плюсуешь к времени разработки. Работает плохо, но лучше, чем ничего.
Большие системы подчиняются законам математического хаоса, бишь нелинейны - и все факторы неизвестности в них вызывают мультипликативный рост сложности. Если проект большой - даже при хорошей декомпозиции на задачи это не значит, что общее время выполнения этих задач влезет в те самые 15-20% прибавки на риск - увы, но тут разброс растет в геометрической прогрессии. Поэтому, собственно, рассчитывать на точность оценки крупного проекта вообще не стоит - тут надо идти итерациями, от MVP.
Штат ИТ-специалистов в компаниях повсюду раздут - где-то больше, где-то меньше. Раздут в том смысле, что задачи зачастую на том же уровне качества и в те же сроки могут быть выполнены меньшим составом, а второе - что и количество самих задач можно ощутимо снизить и не пилить всяческую ересь чисто "штоб было" или "позырить че будет". Компании могли себе позволить это расточительство, теперь же включается режим переоценки.
Но это отдельная, от ситуации с Твиттером, штука - тут речь про то, что шашкой махать - не мешки ворочать. Я Маска дураком не считаю, надо понимать, что и сама ситуация доносится до нас в искаженном виде - что там на самом деле происходит я не знаю, но чисто снаружи, по подаваемой информации - поведение Маска выглядит таким образом, что он сознательно (имеет какой-то свой план) или невольно (слишком сильно затянувшись очередным косячком) хоронит Твиттер.
Большие и сложные системы, которые пишут годами, незамутненной менеджерской гениальностью изменить невозможно по одной лишь хотелке этого самого гения. Твиттер - как раз такая большая и сложная система. Если, как тут где-то писали, 80% функционала отключили и только смс-авторизация отвалилась - то, выходит, разрабы как раз очень хорошо писали софт, раз в него не только фичи добавлялись, но еще и можно эти фичи извлечь из системы без её краха. А вот кто ставит противоречивые задачи и желает побыстрее прикрутить новую "киллер-фичу" - разрабы? Нет, это делают как раз люди, которые потом всегда валят на исполнителей, что их гениальные прозрения неправильно исполнили : )
В общем, в лучшем случае Маску потребуется вбухать кучу бабла, чтобы сделать всё "по-евоному" : ) потому что переделать такую махину как Твиттер - это вообще ни разу не просто, а Твиттер 2.0 - это шляпа, потому что поезд соцсетей уже давно ушел и никакой новизны нету. В итоге и старое (наработанную аудиторию) проимеют, и новое нафиг никому не нужно будет. Таков мой прогноз : )
Следующим этапом будет озарение, что люди в процессе - со всеми своими особенностями - это не аномалия, а часть процесса, которую следует учитывать в первую очередь. А их время - это уже производная : )
Спасибо за статью - познавательно. Однако, что касается сути вопроса - а разве не общепринят подход: multithreading - для кода ввода/вывода, multiprocessing - для CPU-bound?
А еще, если вакансия не горит (и что вполне подходит как раз для крупных компаний, которые "нанимают не на позицию, а в компанию") можно применить экспансивный подход - то есть организовать тест на соответствие ожиданиям нанимателя - чисто для кандидата. Пусть кандидат сориентируется конкретно - что от него ждут. Даже если не прошел тест - ничего страшного, можно подтянуть слабые места - причем конкретные слабые места. Можно так же написать список рекомендаций к изучению - пусть кандидат, при заинтересованности, сам дойдет до нужного компании уровня. Мне кажется это хорошим способом привлекать в компанию подготовленные кадры - и это сэкономит время как нанимателю, так и соискателю.
Автор, как насчет того, что вам банально не хватило компетенции разобраться с Mongo? Не является ли безответственным поручение сложных задач - джунам? Как вы прокомментируете отсутствие тестирования на проекте федерального масштаба?
Вам не кажется, что вы перекладываете ответственность и не замечаете гораздо более существенных проблем, всего лишь следствием которых уже являются описанные вами кейсы?
А это недалеко от истины : ) и актуально для поиска серьезного уровня разработчиков - всё равно же вся петрушка вскроется и, если новоприбывшему не по духу то, как построена работа в нанимающей компании, он все равно её покинет довольно скоро, а, значит, и время на хантинг зря потрачено, и нужно заново искать.
А вот что с другой стороны могу сказать: вакансии работодатели пишут малоинформативные и безликие, нередко - безграмотные и/или неадекватные.
По порядку:
Малоинформативные - те, где нет конкретики даже по используемому стеку, а так же нет приоритетов. Частично такие вакансии еще и неадекватно выглядят, когда в списке требований перечислено всё, о чём когда-либо слышал работодатель. Читая такие списки как минимум очень сложно понять - достаточно ли у тебя компетенции, чтобы претендовать на вакансию? А так же возникают мысли об адекватности писавших эти требования.
Безликие вакансии - потому что крайне мало вакансий с описанием что именно предстоит делать. Поймите - даже адекватного списка профтребований недостаточно, чтобы оценить интерес к вакансии. Что у вас за проект, какое направление, какие особенности? Если вы ищете безликого же кодера - то окей, но если вам нужен мотивированный - напишите с чем именно надо работать, потому что если соискатель уже не джун - ему чаще не все равно с чем работать.
Безграмотные - это где вообще неправильно написаны названия технологий, инструментов, фреймворков и т.д. Shame on you!
Про Неадекватные уже выше пояснил - ну взвесьте вы свои требования, черт побери! Знание, к примеру, PostgeSQL - это что? Поднять и настроить? Сделать распределенную инфраструктуру? Писать запросы на SQL, вьюхи и т.д.? Или это значит только то, что у вас в качестве СУБД - PostgreSQL, а разработчики дальше ORM и не ходят? Насколько это вообще актуально для вакантной позиции? Или это так, на всякий случай?
Сейчас, когда я смотрю на туже выдачу hh, я затрудняюсь понять - что из этого потенциально интересно и мне по силам - как раз ввиду вышеописанного. И поэтому время теряют и работодатели, и претенденты.
Как этот механизм выглядит, когда для управленческих инструментов требуется разнообразными способами агрегировать информацию по тысячам сущностей, в реальном времени по актуальным данным?
Это плохо выглядит везде - хоть в какой архитектуре. Запросы в оперативную базу с разлапистыми джойнами - совершенно не сахар и для самой базы данных, и требуют уже специальных решений - типа отдельной базы данных для аналитики с денормализованными данными или хотя бы отдельной реплики базы. И вот когда эта самая реплика/отдельная база появляются... тут над ними легко и создать микросервис поставки данных.
"Приблизительно ворочать мешки" и "ворочать мешки" - это две большие разницы. Именно здесь чаще всего и возникают недопонимания между заказчиками, которые же приблизительно точно знают чего хотят - и программистами, которые должны уже однозначно точно дать указания компьютеру что он должен делать : ) Впрочем, это лирика. А насчет долженствований - да я просто хотел узнать как именно должна работать ваша идея, ибо в своем приблизительном виде она выглядит для меня наивной по озвученной мной и некоторыми другими участниками нашей беседы причинам. Поэтому надо смотреть "конкретный код", а не оперировать очередными неопределенностями - такая у нас работа.
Как минимум тогда интересно - каким образом вебстриминг, например, и банковская система является типовой относительно друг друга? Вы хотите сказать, что банковские расчеты и логика - это такой вид вебстриминга?
Вы так считаете? На мой взгляд, большинство задач в МИРЕ это у нас есть
какие‑то данные, нужно взять типовые инструменты, сделать типовую
аналитику с типовым фронтов и с типовым беком, сделать интеграцию
типовыми способами и т. д.
Невероятно сильное обобщение. В принципе, все в природе из одних и тех же атомов состоит - значит ли это, что разница между камнем, положим, и человеком - невелика? : )
А я еще раз повторю - чтобы говорить об искажениях оценки надо знать для начала - какая оценка эталонная : ) А когда неизвестно что есть Истина - нельзя сказать и что есть Ложь.
А с чем выплаты связаны? Какова функция расчета раз уж мы тут все такие программисты - нам нужна функция - что на входе и как рассчитывается результат этой функции : ))) А так - это напоминает старинный мем:
1. Быстрота
2. .....
3. PROFIT!!!111
Ну да, для типовой разработки это более-менее работает - вот вы пишите типовые конфигурации 1С, к примеру, имеете штат сотрудников, чьи навыки работы с типовыми инструментами 1С экзаменуете периодически - и да, можете вполне адекватно предсказывать разработку. Но это очень далеко не всё, что происходит в разработке ПО - как раз таки подавляющее большинство - это новые предметные области с новыми подходами и новыми требованиями - и здесь, в этой обширнейшей нише расчеты сроков становятся заметно неточными, потому что нет типовых решений.
Вам же объяснили уже, что в большой системе - нелинейные зависимости между входящими данными и результатом. Так же точно происходит с предсказанием погоды - это же уже исследовалось, и даже понятно почему так происходит - погуглите Эдварда Лоренца с его "эффектом бабочки".
Тут вовсе не рассматривается вопрос стимуляции разработчиков, тут именно что вопрос - а как оценить разработку проекта более-менее приемлемо? Эта проблема не только перед заказчиком стоит, но и перед разработчиком.
Усреднение разных оценок не поможет. Разработчики все с разным опытом, да и опыт одного и того же разработчика изменяется со временем. Это раз. Второе - это то, что любая оценка даже опытнейшего разработчика строится на неопределенности - ну то есть в лучшем случае понимает это, а в худшем - занимается самообманом, который выльется в срыв озвученных сроков, что повсеместно и происходит с малоопытными, но - или, скорее - "потому и" - уверенных в своих оценках, специалистами.
Конечно, бывают проекты, в которых требования достаточно точны и даже имеется опыт их реализации - их оценивать легче и можно не перезакладываться сильно на риск, но даже в таких проектах факторы неверных толкований и вероятных изменений не отменяются и создают риск не влезть в неучитывающий их срок.
Конечно, если вы пишите из года в год примерно одно и то же на типовой платформе, плюс как-то научились контролировать грейд специалистов (обязательной сертификацией/аттестацией, например), то статистический подход еще может помочь, но это довольно узкая область разработки ПО. Подавляющее же число разработок ПО слабо походят на друг друга.
И в любом случае, это про те случаи, когда проект небольшой, по большей части состоит из знакомого по опыту функционала и требования прописаны достаточно детально, а часто - ТЗ состоит из дефиниций "хотелок", без каких-либо деталей и/или требуется "запилить" что-нибудь из разряда "как у Гугла" - только вот заказчик не понимает, что Гугл разрабатывал свою машинерию 30 лет огромными командами и сделал кучу неудачных подходов, прежде чем получил результат.
Проблема в том, что даже в адекватно прописанном в ТЗ и знакомом по опыту функционале всегда остается много неопределенности, если даже вам вдоль и поперек знакома фича по предыдущему опыту - это вовсе не означает что вы:
Точно идентифицировали фичу - вполне может быть, что заказчик подразумевает нечто иное.
Фичи практически никогда не бывают одинаковыми - иначе, как и было подмечено, разработчики бы тупо собирали ПО из давно сделанных кирпичиков - но нет, каждый раз свои нюансы.
Практически ни один проект не обходится без внесения изменений в процессе разработки - как бы там ни божился заказчик и как бы опытен ни был аналитик/архитектор.
Из известных мне и более-менее рабочих способов гадания на сроки - это закладка риска: то есть определяешь сколько по твоему мнению на разработку фичи нужно времени и добавляешь на неопределенность еще 15-20% времени - как раз на то, что фичу неправильно понял, фича будет меняться и/или возникнут другие непредвиденные обстоятельства.
В целом это работает, но не в минимум двух случаях:
Нет опыта реализации подобного - соответственно не от чего отталкиваться. Частично решается тем, что проводишь экспресс изучение темы - хотя бы где и что надо узнать из технологий и сколько времени уйдет на уже изучение исходя из объема материала - плюсуешь к времени разработки. Работает плохо, но лучше, чем ничего.
Большие системы подчиняются законам математического хаоса, бишь нелинейны - и все факторы неизвестности в них вызывают мультипликативный рост сложности. Если проект большой - даже при хорошей декомпозиции на задачи это не значит, что общее время выполнения этих задач влезет в те самые 15-20% прибавки на риск - увы, но тут разброс растет в геометрической прогрессии. Поэтому, собственно, рассчитывать на точность оценки крупного проекта вообще не стоит - тут надо идти итерациями, от MVP.
Штат ИТ-специалистов в компаниях повсюду раздут - где-то больше, где-то меньше. Раздут в том смысле, что задачи зачастую на том же уровне качества и в те же сроки могут быть выполнены меньшим составом, а второе - что и количество самих задач можно ощутимо снизить и не пилить всяческую ересь чисто "штоб было" или "позырить че будет". Компании могли себе позволить это расточительство, теперь же включается режим переоценки.
Но это отдельная, от ситуации с Твиттером, штука - тут речь про то, что шашкой махать - не мешки ворочать. Я Маска дураком не считаю, надо понимать, что и сама ситуация доносится до нас в искаженном виде - что там на самом деле происходит я не знаю, но чисто снаружи, по подаваемой информации - поведение Маска выглядит таким образом, что он сознательно (имеет какой-то свой план) или невольно (слишком сильно затянувшись очередным косячком) хоронит Твиттер.
Звучит как возможность стать "Бриллиантовым партнером" какого-нибудь Гербалайфа - супер круто! : )
Большие и сложные системы, которые пишут годами, незамутненной менеджерской гениальностью изменить невозможно по одной лишь хотелке этого самого гения. Твиттер - как раз такая большая и сложная система. Если, как тут где-то писали, 80% функционала отключили и только смс-авторизация отвалилась - то, выходит, разрабы как раз очень хорошо писали софт, раз в него не только фичи добавлялись, но еще и можно эти фичи извлечь из системы без её краха. А вот кто ставит противоречивые задачи и желает побыстрее прикрутить новую "киллер-фичу" - разрабы? Нет, это делают как раз люди, которые потом всегда валят на исполнителей, что их гениальные прозрения неправильно исполнили : )
В общем, в лучшем случае Маску потребуется вбухать кучу бабла, чтобы сделать всё "по-евоному" : ) потому что переделать такую махину как Твиттер - это вообще ни разу не просто, а Твиттер 2.0 - это шляпа, потому что поезд соцсетей уже давно ушел и никакой новизны нету. В итоге и старое (наработанную аудиторию) проимеют, и новое нафиг никому не нужно будет. Таков мой прогноз : )
Следующим этапом будет озарение, что люди в процессе - со всеми своими особенностями - это не аномалия, а часть процесса, которую следует учитывать в первую очередь. А их время - это уже производная : )
Ну чтош, Илон Маск - поглядим как залетает Твиттер под твоим рукавотством : ) И не долетит ли он тупо до ближайшей корзины с мусором.
Спасибо за статью - познавательно. Однако, что касается сути вопроса - а разве не общепринят подход: multithreading - для кода ввода/вывода, multiprocessing - для CPU-bound?
Это называется KISS.
А еще, если вакансия не горит (и что вполне подходит как раз для крупных компаний, которые "нанимают не на позицию, а в компанию") можно применить экспансивный подход - то есть организовать тест на соответствие ожиданиям нанимателя - чисто для кандидата. Пусть кандидат сориентируется конкретно - что от него ждут. Даже если не прошел тест - ничего страшного, можно подтянуть слабые места - причем конкретные слабые места. Можно так же написать список рекомендаций к изучению - пусть кандидат, при заинтересованности, сам дойдет до нужного компании уровня. Мне кажется это хорошим способом привлекать в компанию подготовленные кадры - и это сэкономит время как нанимателю, так и соискателю.
Автор, как насчет того, что вам банально не хватило компетенции разобраться с Mongo? Не является ли безответственным поручение сложных задач - джунам? Как вы прокомментируете отсутствие тестирования на проекте федерального масштаба?
Вам не кажется, что вы перекладываете ответственность и не замечаете гораздо более существенных проблем, всего лишь следствием которых уже являются описанные вами кейсы?
А это недалеко от истины : ) и актуально для поиска серьезного уровня разработчиков - всё равно же вся петрушка вскроется и, если новоприбывшему не по духу то, как построена работа в нанимающей компании, он все равно её покинет довольно скоро, а, значит, и время на хантинг зря потрачено, и нужно заново искать.
А вот что с другой стороны могу сказать: вакансии работодатели пишут малоинформативные и безликие, нередко - безграмотные и/или неадекватные.
По порядку:
Малоинформативные - те, где нет конкретики даже по используемому стеку, а так же нет приоритетов. Частично такие вакансии еще и неадекватно выглядят, когда в списке требований перечислено всё, о чём когда-либо слышал работодатель. Читая такие списки как минимум очень сложно понять - достаточно ли у тебя компетенции, чтобы претендовать на вакансию? А так же возникают мысли об адекватности писавших эти требования.
Безликие вакансии - потому что крайне мало вакансий с описанием что именно предстоит делать. Поймите - даже адекватного списка профтребований недостаточно, чтобы оценить интерес к вакансии. Что у вас за проект, какое направление, какие особенности? Если вы ищете безликого же кодера - то окей, но если вам нужен мотивированный - напишите с чем именно надо работать, потому что если соискатель уже не джун - ему чаще не все равно с чем работать.
Безграмотные - это где вообще неправильно написаны названия технологий, инструментов, фреймворков и т.д. Shame on you!
Про Неадекватные уже выше пояснил - ну взвесьте вы свои требования, черт побери! Знание, к примеру, PostgeSQL - это что? Поднять и настроить? Сделать распределенную инфраструктуру? Писать запросы на SQL, вьюхи и т.д.? Или это значит только то, что у вас в качестве СУБД - PostgreSQL, а разработчики дальше ORM и не ходят? Насколько это вообще актуально для вакантной позиции? Или это так, на всякий случай?
Сейчас, когда я смотрю на туже выдачу hh, я затрудняюсь понять - что из этого потенциально интересно и мне по силам - как раз ввиду вышеописанного. И поэтому время теряют и работодатели, и претенденты.
Как этот механизм выглядит, когда для управленческих инструментов требуется разнообразными способами агрегировать информацию по тысячам сущностей, в реальном времени по актуальным данным?
Это плохо выглядит везде - хоть в какой архитектуре. Запросы в оперативную базу с разлапистыми джойнами - совершенно не сахар и для самой базы данных, и требуют уже специальных решений - типа отдельной базы данных для аналитики с денормализованными данными или хотя бы отдельной реплики базы. И вот когда эта самая реплика/отдельная база появляются... тут над ними легко и создать микросервис поставки данных.