Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса.
Этот тезис больно ударит по вашему самолюбию, если вы привыкли к уровню обслуживания «нет в ТЗ – идите мимо». Тем не менее, если вы хотя бы чуть-чуть поменяете свое мнение в сторону большей клиентоориентированности, то сможете понять, о чем я.
Знаю-знаю, вы – крутой программист и тут же возразите мне – а что же, я должен предвидеть все, что нужно бизнесу? Должен догадаться, чего хочет заказчик? Бесконечно реализовывать его странные хотелки?
А имеете ли вы моральное право задавать такие вопросы? Проверьте, что из этого списка вы сделали для этого:
Провели ли вы предварительный анализ требований из ТЗ, прежде чем приступить к его реализации?
Поставили ли вы под сомнение какие-либо пункты в спецификации или просто
взяли под козырекполучили аванс?Предложили ли вы заказчику альтернативные варианты решения?
Если ваш ответ «ничего», значит вы просто формалист, перекладывающий ответственность с себя на заказчика.
Вы до потертости пальцев будете тыкать в ТЗ, говорить, что оно утверждено и подписано заказчиком. Что он сам виноват в том, что не углядел/не дописал, а теперь топает ногами и требует, чтобы вы доделали работу, но никогда не признаетесь, в том, что не смогли здраво оценить свои силы, потому как некомпетентны.
Знайте, если вы так делаете, то вы низкоквалифицированный программист-техник, не больше!
Нужны обоснования? – пожалуйста.
Что говорит профстандарт о вашей квалификации?
Вы наверняка знаете, что есть так называемые профессиональные стандарты. Они разработаны компетентными органами с целью определить эталонные навыки и умения специалистов, отвечающих за свою работу.
Здесь находится профстандарт для программистов. Это сайт министерства труда.
Если мы заглянем внутрь профстандарта, то обнаружим, что одна из трудовых функций программиста выглядит так:
Написание программного кода с использованием языков программирования, определения и манипулирования данными
В рамках этой трудовой функции определены следующие трудовые действия:
Создание программного кода в соответствии с техническим заданием (готовыми спецификациями)
Оптимизация программного кода с использованием специализированных программных средств
Оценка и согласование сроков выполнения поставленных задач
Действительно, исходя из этого стандарта, мы видим, что программист создает программный код, опираясь на техническое задание (готовую спецификацию). Для этого ему достаточно владеть синтаксисом выбранного языка программирования, уметь оптимизировать программный код и проводить оценку работ по срокам.
Интересно, что программист, который обладает навыками кодинга по ТЗ, получает от Минтруда только 3 пункта к квалификации. Это программист уровня ПТУ, совершенно обоснованно в терминах профстандарта именуемый «Младший программист» или «Техник-программист».
Такой специалист может заявить: «В ТЗ этого нет». Формально он будет прав – это его уровень. При этом ему все равно, реализована ли задача бизнеса, главное, что свою часть работы он сделал.
Аналогом такого подхода могут служить следующие примеры:
Лампочку вкрутил, но свет есть только в 70% теплицы. Для появления завязей необходим уровень наполняемости светом 99%.
Реализовал функцию оплаты заказов, при этом не учел, что оплачивать заказы могут только зарегистрированные пользователи.
Сделал парсер для сайта, но подтягиваемые данные выводятся вкривь-вкось.
Смотрим далее. Есть такая трудовая функция как
Анализ требований к программному обеспечению
А вот это уже посложнее будет, ведь для того, чтобы реализовать столь очевидно-полезную для бизнеса трудовую функцию, действительно нужен фундаментальный подход и мозги, а также пресловутые софт-скилс, которыми не обладают «техники» квалификации 3.
Читаем состав трудовых действий:
Анализ возможностей реализации требований к программному обеспечению
Оценка времени и трудоемкости реализации требований к программному обеспечению
Согласование требований к программному обеспечению с заинтересованными сторонами
Оценка и согласование сроков выполнения поставленных задач
И необходимые умения:
Проводить анализ исполнения требований
Вырабатывать варианты реализации требований
Проводить оценку и обоснование рекомендуемых решений
Осуществлять коммуникации с заинтересованными сторонами
Здесь на первый план выходят социально-ориентированные навыки специалиста: умение общаться, задавать вопросы, вести дискуссию, в чем-то отстаивать свою позицию, где-то прислушаться к иной позиции.
Нетрудно заметить, что из 4 трудовых действий и 4 необходимых умений присутствуют только 2 технических навыка!
А теперь немного о том, как называется эта должность и уровень необходимой квалификации:
Становится очевидным, что для того, чтобы быть в авангарде своей профессии и приносить бизнесу пользу, нужно быть не просто человеком-печатной машинкой кода, а аналитиком.
Вы имеете право говорить о «бесконечных доделках», если вы:
Предварительно и в полной мере убедились, что требования, положенные в ТЗ, определяются бизнес-задачей и неразрывно связаны с ней.
Задали заказчику исчерпывающие вопросы и утвердились в понимании «почему» и «зачем» необходимо реализовать ту или иную бизнес функцию, в результате которой родились функциональные требования, описанные в ТЗ.
Другими словами программист, обладающий развитыми аналитическими навыками, в любой момент времени понимает, как именно конкретное функциональное требование соотносится с бизнес-задачей и наоборот – какой бизнес-задачей порождено соответствующее функциональное требование, на что оно опирается.
И называется такой программист ведущим!
Для него подход «такого не было в ТЗ» – катастрофа, ведь он осознает, что ТЗ – это сфера его ответственности. Ведущий программист выполняет 60% работы на этапе аналитики и только 40% отводит на работу с кодом. Он не делает ТЗ притчей во языцех, доказывая несостоятельность заказчика. Скорее, наоборот, он чувствует себя несостоятельным, если, сделав работу по ТЗ, заказчик получает не тот результат, на который рассчитывал.
Это колоссальная разница в подходах и мышлении – заметьте!
Если программист не видит связи задач с бизнесом и не принимает каких-либо действий для обнаружения такой связи, то это программист-техник.
Как перестать быть программистом-техником и выйти на уровень компетенций ведущего программиста?
Чтобы соответствовать высоким показателям Минтруда и ожиданиям заказчиков нужно, в первую очередь, переориентировать фокус своего внимания с технической части на бизнес. Хороший аналитик – это всегда про взаимопонимание людей. Нужно учиться общаться, задавать вопросы, интересоваться той сферой деятельности, потребности которой вы решаете. Аналитик должен знать и предметную область проекта, и применяемые техники разработки.
Вот примерный спектр умений для прокачки в себе аналитика и успешного бизнес-коммуникатора:
Анкетирование. Умение сделать качественную анкету под проект можно считать базовым навыком перед тем, как вступать в очные интервью.
Навык индивидуального интервьюирования. Сюда можно отнести персональные встречи, интервью по телефону и навыки выявления требований посредством переписки.
Групповые интервью. На групповых интервью присутствует несколько заинтересованных лиц. Ничего сложного. Просто здесь лучше проявляются ваши навыки самопрезентации, умение владеть вниманием собеседника, задавать вопросы и удерживать формат беседы, необходимый для получения результата.
Наблюдение. Иногда, для того, чтобы понять, как что-то работает, достаточно просто понаблюдать за этим. Уверяю, что посидев полтора часа в живом отделе продаж и просто наблюдая за менеджерами, вы точно поймете, как адаптировать эту злосчастную CRM так, чтобы руководство осталось довольным.
Прототипирование и создание бизнес-схем с последующим их обсуждением. Прототипы великолепны в качестве первого приближения результата. Если вы пришли на встречу с клиентом или общаетесь с ним в формате конференции онлайн – разверните флип-чарт и порисуйте. Ваша дискуссия обретет иной качественный характер и понимание.
Кроме того, рекомендую почитать следующую литературу:
Карл Вигерс, Джой Битти – Разработка требований к программному обеспечению. Практические приемы сбора требований при разработке программных продуктов.
Дин Леффингуэлл, Дон Уидриг – Принципы работы с требованиями к программному обеспечению. Унифицированный подход.
Этот перечень неограничен, но вполне достаточен на начальном этапе, чтобы открыть себе путь к более интересным проектам. Это ваш иной уровень зрелости как специалиста с доступом к другому уровню вознаграждения.
Удачи вам и крутых проектов!
Комментарии (186)
saipr
11.04.2022 23:32+3Действительно, исходя из этого стандарта, мы видим, что программист создает программный код, опираясь на техническое задание (готовую спецификацию). Для этого ему достаточно владеть синтаксисом выбранного языка программирования, уметь оптимизировать программный код и проводить оценку работ по срокам.
Так и хочется воскликнуть:
— А судьи кто? — За древностию лет
К свободной жизни их вражда непримирима,
Сужденья черпают из забытых газет
Времен Очаковских и покоренья Крыма;
Автор
А. С. ГрибоедовКак здорово, что нас учили, руководствуясь словами, которые можно назвать мировым стандартом на программиста, выдающегося советского учёного, одного из пионеров теоретического и системного программирования академика Андрея Петровича Ершова (статья «О человеческом и эстетическом факторах в программировании», 1972):
Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста.
TimsTims
12.04.2022 01:40+12Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста.
Раньше когда писали машинный код, и память была суперограничена, то действительно программистами были только настоящие гении, оптимизирующие каждый такт процессора 0x5f3759df. Даже собеседования было проводить легко, ведь человек либо понимал о чем говорит, либо абсолютно не понимал.
Но сейчас то всё настолько высокоуровнево, что 90% программ - это просто разного рода CRUD'ы, разные интеграции между программами, перекладывание информации с одной проги в другую, и рисование интерфейсов, а памяти - хоть жопой жуй.
Остальные 10% сложных (скажем так - с высоким порогом входа) - это high-load проекты, и machine learning. Требования к сверх-гениальности в индустрии разработки давно уже снизились.
N-Cube
12.04.2022 09:04+1Эк вы все научное ПО проигнорировали. Наверное, уверены, что одной левой пяткой напишите софт для компьютерного моделирования лекарств или там спутниковой интерферометрии?
TimsTims
12.04.2022 11:39+4Конечно, есть ещё довольно много сфер, где всё требования высокие. Я не ставил целью посчитать точные проценты (90% и 10% взяты из головы и не имеют обоснования), и не ставил целью своим комментарием провести научное исследование по ИТ-сферам и требуемым компетенциям, а хотел обозначить разницу между требованиям к программистам тогда (50 лет назад в 1972), и сейчас в 2022.
N-Cube
12.04.2022 20:23-1Ну так 50 лет назад не существовало ни радарных спутников высокого разрешения с общедоступными данными на всю планету, ни софта для их обработки в облаке, доступного непосредственно в веб-браузере любому желающему. Как вообще можно сравнивать? Если вы серьезно считаете, что какой-нибудь солвер на фортране написать сложнее, то вынужден вас разочаровать…
TimsTims
12.04.2022 20:39+4Ещё раз. Я не говорю, что работа со спутниками сейчас стала простой, и что не осталось сложных задач. Я говорю о том, что 50 лет назад, чтобы написать любую программу - начиная с игры на денди, заканчивая какой нибудь микробухгалтерии ты должен был быть уже неплохим таким специалистом с очень крутыми скиллами. Сейчас эти же самые задачи выполнит даже начинающий разработчик, ничего гениального для этого не нужно. Из этого следует, что требование:
должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц
Именно это требование более не актуально.
karon
12.04.2022 12:07+2А тут сложность именно разработки или знания предметной области?
domix32
12.04.2022 19:40-1В случае с научным ПО - в первую очередь разработки: знания аспектов инфраструктуры используемого языка в первую очередь - библиотеки, оптимальные алгоритмы/контейнеры и прочее в том же духе. Особенно плохо если ко всему этому ещё нет и какой-то минимальной верификации написанного. Ну и велосипеды с костылями, куда же без них. Если у нас есть некоторый железный аппарат, то сложность разработки ещё подрастает, причем независимо для аппарата софт, или для обработки данных с оного аппарата. Сама предметная область которую можно закодировать относительно простая - сюда map, туда reduce, туда фурье, сюда интеграл, смыть, намылить, повторить.
Особнячком тут всякие SAT-солверы и прочие логические proof assistant, тут уже предметная область обычно сложнее.
karon
12.04.2022 22:59+1Я с радио сигналом работал. Самая сложная часть была именно физика.
А так данные и данные. Видимо у каждого свои проблемы
Ndochp
13.04.2022 10:46Часто физика не проблема, а вот загнать весь объем данных быстро в настольный ПК, чтобы не привлекать сторонних ресурсов…
Очень часто физические задачи по "честным" физическим формулам в прямом подходе не влезают то по памяти, то по быстродействию, то по точности (кровоток в институте считали)
K0styan
13.04.2022 11:08+1Работал в некотором НИИ (CV на эмбеде), так у нас был тандем разработчиков. Один - чистый математик, орудовал Матлабом и подобными пакетами. Второй - программист, писал непосредственно код, втискивая математику первого чувака в ресурсы DSP и ПЛИС. Так что многофакторность сложности задач была сбалансирована подбором специалистов.
DarkTiger
12.04.2022 13:32+4Работал с приложениями, написанными специалистами исключительно в предметной области. Первое такое приложение было на ЕC1040, в 1993, нас, студентов, гоняли в Бауманке считать прогиб балки по сопромату. Рассказал бы про впечатления, да мат на Хабре запрещен.
dnazarov007
13.04.2022 20:50+2Про софт софт для компьютерного моделирования лекарств ничего не скажу, но когда мне коллега популярно объяснил, что такое спутниковая интерферометрия, понял, что ничего там нет сложного... )
TimsTims
14.04.2022 17:30Мне Паваротти не понравился, картавит, в ноты не попадает...
- Вы были на концерте Паваротти?
- Нет, мне Рабинович по телефону напел
kle6ra
12.04.2022 09:26+3Я с вами тут немного не согласен, низкоуровневую разработку никто не отменял (ещё процентов 10-15 можно накинуть). В большинстве железячных проектов очень часто приходится разбираться в особенностях микроконтроллера или процессора, работать с таймингами, памятью, прерываниями, кастомными протоколами передачи данных, проводить реверс инжиниринг вообще в порядке вещей из-за частого отсутствия нормальной документации и т.д. Особенно в текущий момент времени, когда все заказчики просят сделать подешевле, а из-за дефицита железа это чаще всего переход к менее мощному железу или очень непопулярному железу, где многие вещи нужно реализовывать самому.
zuek
12.04.2022 17:51Лет 5 назад пришлось стряхнуть пыль с тех извилин, которые в начале 90-х занимались программированием - ввязался в стартап, где на какой-то STM'ке делали интерактивный пульт, работающий по I2C... там, конечно, не голый asm в среде без окружения, но RTOS в полный рост... долго ловил нужные тайминги, чтобы I2C нормально поднялась... но потом пришёл разработчик интерфейсной части и попортил всю малину - работал либо тачскрин, либо I2C... так и отвалился я от того проекта, не став embedded-программистом.
z0ic
12.04.2022 20:50+3Эти два слова неотделимы.
saipr
12.04.2022 21:01+1Именно так. И эти два слова коррелируются с высказыванием академика Ершова А.П:
Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста.
ky0
11.04.2022 23:35+34Жаль, что между человеком, к которому обращается автор, и заказчиком, задачи которого этот человек должен решать, нет никаких промежуточных людей. Как хорошо было бы, чтобы, не знаю… какой-то человек, более заточенный под общение, выяснял потребности бизнеса и хоть слегка формализовывал бы их; другой человек проводил анализ (я бы прямо так его и назвал — аналитиком), ну и так далее.
Вот бы тогда зажили — можно было бы кодить по ТЗ, не подтягивая всех программистов до уровня «ведущего». А то ещё, гляди, все захотят и зарплату «ведущую» — то-то заказчик обрадуется в разы увеличившемуся счёту.
Kanut
12.04.2022 09:28+2Проблема в том что хорошего бизнес-аналитика найти ещё сложнее чем хорошего программиста. А если даже и найдёшь, то зарплату они хотят тоже не меньше чем программисты. Мягко говоря.
Поэтому как минимум у нас "бизнес-аналитик" это часто просто один из вариантов развития карьеры программисты после сениора. Наряду с тимлидом и архитектом.
Ну и точно так же как и в случае с тимлидами/архитрктами многие просто совмещают это с программированием в тех или иных пропроциях.
Stas911
12.04.2022 17:58+1Бизнес-аналитики часто пишут такую хрень, что ее невозможно реализовать и иногда между ними и программистами еще есть systems analyst/functional analysts, которые как раз с техническим бэкграундом приводят сказочные хотелки к реалиям.
AlfaStigma
14.04.2022 09:32Заказчик говорит что он хочет
Аналитик говорит что надо сделать
Техлид/Архитектор говорит как это надо сделать
Программисты делают)
sshikov
12.04.2022 20:53+1>Поэтому как минимум у нас «бизнес-аналитик» это часто просто один из вариантов развития карьеры программисты после сениора.
Не знаю, где это там «у вас», в моей практике обычно такие люди вырастали из QA. Которые в силу своей деятельности обычно умеют пользоваться написанным софтом по назначению, а также знают, как оно должно быть, потому что читали требования. А вот как раз программистов, выросших в бизнес аналитика, не встречал за примерно 30 лет никогда.
AlexunKo
13.04.2022 20:48Поэтому как минимум у нас "бизнес-аналитик" это часто просто один из вариантов развития карьеры программисты после сениора. Наряду с тимлидом и архитектом.
Поэтому?.. Только из-за денег у вас такой странный карьерный "кульбит"?
Kanut
13.04.2022 20:52В том числе и из-за денег. Кроме того "лепить 100500-й crud" в какой-то момент тоже становится скучно. А тимлидами иои архитектами тоже не все могут или хотят становиться...
AlexunKo
13.04.2022 21:49Ну, наверное, если внушить людям то что это "один из вариантов развития карьеры программисты после сениора" то можно. Но, синьор ли тот кто не увидит в этом подвоха.
Kanut
13.04.2022 22:25Да никто никому ничего не внушает и никто никого ни к чему не принуждает.
AlexunKo
13.04.2022 22:49-1Тогда непонятно откуда взяться идее что это развитие, а не переквалификация.
Kanut
13.04.2022 22:51Ну во первых а у чём принципиальная разница? А во вторых большинство при этом продолжает часть времени кодить.
AlexunKo
13.04.2022 23:02-1Как вариант занять людей, которым неинтересно работать по своему профилю чем-то ради хоть какой-то новизны - да. Но в подмене отдушина-развитие может скрываться банальная манипуляция.
Ndochp
14.04.2022 08:57+1Я например считаю, что программист — это создатель систем. Значит его развитие должно идти по направлению увеличения производительности/влияния на создание систем.
Джун — делает что скажут, но вносит свои кирпичики
Мидл — хорошо делает порученный кусок принимая тактические задачи
Синьер — менторит джунов принимает частично-архитектурные решения
Дальше вилка:
Архитектор (кодовый) — принимает решения, как технически будет устроена система
Тимлид — может больше чем один программист, так как ведет команду
РП — отрыв от собственно кода, руководство созданием системы в полном объеме (но по чертежу от аналитиков)
Бизнес аналитик — принятие решений, а какой собственно будет система.
0xd34df00d
14.04.2022 06:17Если лепить 100500-й круд становится скучно, то можно пойти туда, где надо будет лепить что-то более интересное.
karon
12.04.2022 00:33+35Такое ощущение, что логика автора 1 проект - 1 программист. Больше в команде никого нет, и не предвидится.
anaken
12.04.2022 09:40+2Скорее всего автор описывает свою текущую боль)
В разных компаниях все по разному - в более мелких, программистам не редко приходится выполнять кучу разных ролей: аналитик, программист, тестировщик, девопсер, тех.писатель. Не редко в мелких компаниях и стартапах как такового ТЗ и вовсе нет. В более крупных компаниях разделение труда встречается гораздо чаще, в таких компаниях программисты чаще всего занимаются разработкой приложений строго по ТЗ, и отступление от него не то что не приветствуется, а очень даже наказывается.
siziyman
12.04.2022 10:57+3В известных мне крупных продуктовых IT-компаниях как раз программисты, которые могут подумать головой - дозаполнить какие-то пропуски в постановке задачи или указать на её неполноценность/некорректность, предоставить какой-то пушбэк - ценятся куда больше, чем "программисты по ТЗ".
Если речь о каком-нибудь там галерном аутсорсе, то да, там другой мир, но там совсем неинтересный мир для рядового разраба, как по мне.
Nialpe
12.04.2022 12:19Особенно вы правы для случаев, когда тз ставится аналитиком, который сам мягко говоря пофигист.
anaken
12.04.2022 12:29+2Чем больше компания, тем больше в ней бюрократии и тем меньше участие конечного программиста в ТЗ.
siziyman
12.04.2022 12:31+1Пойду расскажу знакомым гуглерам и прочим сотрудникам фэйсбука, чо.
Да и сам как бы в компаниях с тысячами сотрудников работал и работаю - нет ничего подобного. Да и ТЗ, строго говоря, очень часто нет.
sshikov
12.04.2022 20:57+1Это, пардон, как минимум излишнее обобщение. Большая компания зачастую — это просто много проектов. Из этого никак не следует, что в каждом проекте людей много, и никак не вытекает уровень бюрократии внутри проекта. Вот у меня компания не просто большая, а очень большая, а проект при этом состоит из шести человек, три программиста, два аналитика и QA (не считая отдельной команды поддержки). И зачастую программисты просто оное ТЗ сами и пишут, и никакой бюрократии (во всяком случае в этом процессе) вообще нет.
shornikov
13.04.2022 11:37+1В крупных компаниях любят KPI и там наверняка не учитываются доработки ТЗ.
А попытки объяснить, что не так в ТЗ - это весьма немалые временные затраты.
Stas911
14.04.2022 03:10Какая разница, если все равно заказчику оплачивать время? (Если контракт "Time & Material", а сейчас большинство такие)
vism
13.04.2022 20:17В больших компаниях такие разработчики очень быстро становятся теми, кто эти ТЗ вобщем-то пишет для тех, кто занимается разработкой строго по ТЗ, т.к. они им не хватает предприимчивости для анализа бизнес процессов и идей для улучшения.
Stas911
14.04.2022 03:15В крупных компаниях рост обычно строится по следующим принципам:
"Может написать код по ТЗ"
"Может понять, что нужно заказчику и написать код" (senior)
"Может аргументированно показать заказчику, что он все придумал неправильно и рассказать, как надо сделать по-хорошему" (principal)
Так что "чистые кодеры" обычно так и остаются на первом уровне без всяких promotions.
vism
14.04.2022 13:25Может аргументированно показать заказчику, что он все придумал неправильно и рассказать, как надо сделать по-хорошему
Я не знаю, это вы пошутили или нет, но так действительно частенько бывает с клиентами :)
Stas911
14.04.2022 16:40Какие шутки - это почти дословный пересказ нашего leveling guide.
Я когда нанимаю профессионалов (типа строителей или бухгалтера) я тоже ожидаю, что они если нужно скажут - "чувак, ты придумал дичь, это плохо поэтому и поэтому, давай сделаем вот так и это будет хорошо". Собственно для того и нужны профессионалы. Если компания делает автомобили, то глупо ожидать, что они будут так же хорошо разбираться в ИТ.
iMedved2009
12.04.2022 02:44+9Треугольник Хопкинса "быстро, качественно, дешево" лишь один и вариантов тройственной ограниченности. В случае с ТЗ, будет свои варианты - точные сроки, точный бюджет.
Если клиент готов вести разработку по варианту "пилим пока мне не понравится", не вопрос, вопросы будут только если он при этом потребует что бы ему сказали точную сумму, и точные сроки, и не хрена не захочет понимать когда ему начнут задвигать что отрицательный результат в таком варианте работы - тоже результат, который надо оплачивать.
RTFM13
12.04.2022 03:20+6Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса.
Типичная стратегия внешнего подрядчика по-умолчанию.
shornikov
13.04.2022 11:41Нормальная стратегия. Если ты сам переписал ТЗ и сделал как считаешь нужным - оставь это себе и заплати сам.
Ndochp
13.04.2022 13:34+2Клевая стратегия. Прямо недавно её в хирургии видел.
Ситуация: пациента уложили на стол, усыпили, а потом хирург "ни шмагла"
Тете объясняли, что абсолютно честно не берут с неё денег за операцию. Но берут за анестезию. Так как консультация с анестезиологом была, лекарства на усыпление потрачены, и даже живой её разбудили.
А тетя пыталась объяснить, что без операции ей эта анестезия даром не нужна. А тем более за те деньги, что с неё содрать пытаются.Вот прям каноничный случай поэтапной оплаты по ТЗ.
Хотя… типичные внешние пусть так и делают. Те, кто берут денег за решение проблем, а не выполнение работ будут в плюсе. Сарафан благо работает.
shornikov
13.04.2022 15:35+2Ваш пример про хирургию - он за мой комментарий. У тетки было тз, медики его переписали по своему - остаются без денег.
Если вам дали ТЗ - то вы не решаете проблему, вы производите работы по ТЗ. Комментировать ТЗ можно конечно. Моя практика показывает, что обычно ты теряешь время на объяснения граничных случаев, если речь о реализации, и натыкаешься на "не учите меня делать бизнес" в чем-то более глобальном. Ну а если ты "такой важный куриц", пришел с ТЗ - зачем я буду тебя учить?
Пришел бы с проблемой - решали бы проблему.
Если вы строитель отделочник - вы просто клеите обои, а между тем - в основе всей движухи был тезис (проблема) "нам нужна просторная квартира для нас, детей и собаки". Вы ведь не будете покупать собаку или квартиру заказчику?
Rikkster
12.04.2022 03:41+9Автор полностью прав. В начале карьеры как раз был таким программистом который требовал от заказчика всё учесть в ТЗ, хотя заказчики в большинстве своём сами не представляли что им нужно. Ладно хоть со временем я осознал что именно своей компетенцией могу предложить то, что действительно нужно. И с тех пор стал особенно ценен для заказчиков. Так что если кто не верит автору - подтверждаю истинность вышеописанного собственным опытом.
eaglebuk
12.04.2022 09:08+14Если заказчик не знает, чего хочет, то разве это проблема программиста? Пусть узнает и приходит. Аналитики, консультанты, менеджеры, проектировщики - есть, к кому обратиться. Не надо всю ответственность перекладывать на программиста, называя его к тому же низкоквалифицированным. Без внятного техзадания есть шанс всё постоянно переделывать из-за меняющегося настроения.
PS. А если программист all-in-one, то и цена за его услуги должна быть соответствующей.
Rikkster
12.04.2022 09:13+3Вот и я раньше так рассуждал. ИМХО лучше вовремя внести свою лепту, чем работать над проектом, зная что он станет мертворожденным. Профессионал на то и профессионал, что разбирается в том что делает, и знает как нужно делать а как нет. Другой вопрос, что проектирование архитектуры проекта - отдельная работа, которая требует доплаты, с этим никто и не спорит.
haldagan
12.04.2022 10:12заказчик не знает, чего хочет
Заказчик почти всегда хочет увеличения прибыли. Поэтому он приходит к разработчику с запросом "хочу автоматизировать вот это вот" или "сделайте мне аналог вот этой штуки".
Зачастую заказчик имеет какое-то представление о том, как это должно выглядеть в целом, но не имеет совершенно никакого представления о том, как это будет выглядеть в деталях.
В этом случае задача аналитика или "тыжпрограммиста" - путем изучения предметной области и допроса заказчика по шагам узнать:
Не хочет ли заказчик странного (действительно ли запрошенный продукт решит озвученную проблему бизнеса).
Понимает ли заказчик объемы предстоящих работ ("вот вам миллион, сделайте мне вконтакте" - редко, но случается).
Вместе с заказчиком и конечными пользователями (где применимо) описать все частные случаи глобальной проблемы и заодно выяснить, решаемы ли они.
Составить детальное ТЗ, которое будет прозрачно и понятно как заказчику, так и исполнителю.
Наличие ТЗ обычно подразумевает, что предыдущие три шага уже пройдены (либо с вами либо с какой-то "предыдущей конторой"). Если это не так и вы беретесь за разработку на основе такого ТЗ - у вас с очень большой вероятностью будут проблемы по итогу (либо заказчик "не работает как надо - платить не буду", либо разработчик "на эту фичу еще два месяца работы, а в ТЗ ее нет - бесплатно делать не буду").
P.S.: В общем если возникает проблема "в ТЗ этого нет" - то это недосмотр того, кто ТЗ составлял.
Если ТЗ делали вы, то и ответственность на вас. Если это делал кто-то до вас, то вы просто должны донести до заказчика, что ТЗ не ваше и за отсутствие в нем фатальных недостатков без тщательного аудита вы не ручаетесь.
megabax
13.04.2022 07:52Если ТЗ делали вы, то и ответственность на вас.
Нет, ответственность за ТЗ на том, кто его согласовывал и подписывал. То есть на заказчике. ТЗ вообще для чего нужно? Чтобы формализовать задачу. Чтобы убедится, что программист правильно понял заказчика. ТЗ - это по сути, договор. Перед подписанием ТЗ заказчик его читает и всегда может сказать, что "надо добавить это это это" или "это это это убрать/переформулировать". А если заказчик подписал ТЗ, значит он согласен со сроками, объёмом работ и стоимостью и все то, что не вошло в ТЗ за доп. плату.
haldagan
13.04.2022 08:45+2Я не спорю с тем, что договор есть договор и исполнитель имеет право заниматься буквоедством в случае с ТЗ.
Я о том, что я считаю морально безответственным поступком браться за работу над проектом не убедившись в том, что ТЗ соответствует ожиданиям заказчика и что заказчик действительно понимает, что именно у него написано в ТЗ, поскольку ТЗ зачастую составляет либо (вероятно) некомпетентный в составлении ТЗ заказчик, либо компетентные, но (иногда) незаинтересованные в результате третьи лица.
Я не говорю, что вы обязаны проводить полный аудит ТЗ бесплатно, однако если вы прочитали ТЗ, заметили какие-то логические нестыковки и не попытались выяснить в чем же дело, то вы гарантированно поимеете проблем на сдаче.
momai
12.04.2022 10:19+1Мне кажется, тут проблема рассуждений в плане "ответственности". Это все не про ответственность, а про повышение собственного скилла. От прогера не должны требовать сбора информации от заказчика, однако он должен стремиться разобраться самостоятельно. Это просто повысит тебя как специалиста.
siziyman
12.04.2022 11:02+1Если заказчик не знает, чего хочет, то разве это проблема программиста? Пусть узнает и приходит.
А чего хочет программист? По-моему, сидеть, понимать, что тебе дали задачу "делать какое-то говно" и ожидают, что ты будешь молча сидеть и делать говно - это ад наяву просто. Я проверял, я не могу работать в аутсорсе, выгорание наступает уже позавчера.
PS. А если программист all-in-one, то и цена за его услуги должна быть соответствующей.
Естественно, потолок заработка это тоже увеличивает. Как и список компаний, где вам (/мне/другу сына маминой подруги) будут рады как специалисту.
Stas911
12.04.2022 18:01Мы говорим не про обезьяну-кодера или про профессионального программиста-ИТ-консультанта? В этом между ними и разница.
thesame
13.04.2022 20:08+1Заказчик как раз обычно знает, чего он хочет. Как бы это странно ни звучало. Просто свои пожелания он выражает на своем языке. Условно говоря, один говорит на хинди, другой на суахили, а для общения между собой они используют google переводчик.
Сейчас же я хотел сказать о другом, что путь "пусть узнает и приходит" - тупиковый изначально. Потому что грамотный заказчик найдет толкового тематика - именно так раньше назывались люди, которые писали ТЗ для конкретной задачи. Потом это стало называться, вроде бы, проект-менеджером. Как сейчас, не знаю. Архитектор - это тот, кто проектирует решение по готовому заданию. Так вот, тематик напишет ТЗ, в котором будет предусмотрено все, что только возможно, все варианты интерфейса, все алгоритмы обработки данных - садись и кодируй. Только (surprise!) 80-90% бюджета уйдет тематику, а кодеру - 10-20%.
Поэтому вариантов нет: если речь идет об IT-компании или хотя бы команде, то нужен минимум один "полиглот", если речь об одиночке - ему придется самому стать "полиглотом".
RegisterClassEx
12.04.2022 03:50+35Имхо, фигня в профстандарте написана. Junior? Middle? Senior? Нет, только "инженеры-программисты", только хардкор.
Люди, писавшие профстандарт, ни пса не понимают в программировании. Постановщик требований - целая специальность. Бизнес-аналитик, системный аналитик, проектировщик интерфейсов, системный архитектор, специалист по программно-аппаратным платформам, проектировщик алгоритмов, кодер, тестировщик - это всё разные люди. Разделение труда, всё по Адаму Смиту. И только динозавры в профстандарте ждут, что придёт "тыжпрограммист" и во всём разберётся и сделает всем хорошо, и угадает то, чего заказчик, профессионал в предметной области, не угадал. Ага, щаз пойду интервьюировать, а потом сяду код писать, и тесты ещё, и блок-схемы алгоритмов по ГОСТу для некрофилов нарисую.
Заминусуют - ну и плевать.
vconst
12.04.2022 04:23+8Судя по сему, автор: программист-оркестр, полный фуллстек в одном лице, от переговоров с заказчиком и до бета-теста все делает сам, берется за небольшие заказы и мучается с ними - годами
RegisterClassEx
12.04.2022 11:12+2Когда один человек делает всё это, получается обычно так:
Олег за всё берётся смело,
Всё превращается в говно,
А если за говно берётся,
То просто тратит меньше сил.
FGV
12.04.2022 06:03+4Junior? Middle? Senior?
Junior = техник минус программист;
Middle = инженер минус программист;
Senior = ведущий инженер минус программист.
У техника/инженера еще категории есть. Что не так то?
RegisterClassEx
14.04.2022 17:06Не так то, что у Seniora обязанностей по профстандарту и анализ требований, и бизнес-анализ, и системный анализ, и эргономика интерфейса, и архитектура.
FGV
14.04.2022 20:09И? Собственно:
Что мешает то же самое делать ведущему инженеру? Или что то поменяется от того что ведущего назовут синьором?
При чем тут профстандарт вообще? Обычно от работника требуют выполнение "должностных инструкций", а там уже работодатели пишут все то что необходимо от ведущего./инженера/техника.
pae174
12.04.2022 09:45блок-схемы алгоритмов по ГОСТу для некрофилов нарисую
Я видел такго перца на собесе, который в ответ на просьбу сделать дома тестовое и прислать его, на самом деле распечатал код тестового на листе бумаги формата А4 с этой рамкой по ГОСТ и потом припёрся в офис с этим листом что бы передеть его тимлиду через секретаршу. А меня так учили (С).
RegisterClassEx
12.04.2022 11:37+4А какую рамку? По ЕСКД или по ЕСПД? *истерично смеётся*
Ну, если код нормально написал, то это лечится)
Ndochp
12.04.2022 12:41То что джун-мидл-сеньер называются "младший программист" (освещен в статье) — программист (не освещен) — ведущий программист (освещен) вас как-то особенно больно ранит?
Да, вся указанная вами толпа народа — это разные роли и могут быть разные люди. Их еще и разное количество (пропорционально) на проекте нужно.
В назвали 9 ролей, с учетом разной представленности в сбалансированной команде будет минимум в раза больше народу (на одного архитектора нужна пара бизнес аналитиков, пяток кодеров, тройка тестировщиков и тд).
По вашему командой меньше чем из 30 человек для создания бизнес софта лучше не собираться?
Vezyk
14.04.2022 16:38Все абсолютно верно пишешь, разве что забыл указать, что саппорт продукта ещё отдельный и желательно не связанный ни с заказчиком, ни с исполнителем) Только вот и ответственность получается размытой между всеми звеньями и в итоге "косяки" циркулируют по кругу между всеми звеньями, перебираясь из старой ветки в новую в бесконечном цикле))
Я не критикую, я как тот китаец за течением реки наблюдаю)
Ещё, мне показалось, что автор писал больше про контекст ответственности, чем про техпроцесс, как таковой.
RegisterClassEx
14.04.2022 16:54Насколько я знаю профстандарт, никаких должностей типа "бизнес-аналитик", "системный архитектор", не говоря уже про "архитектора базы данных" там нет. Всё это должен уметь делать "ведущий инженер-программист". Обязанностей у него выше крыши, как и требований "должен знать", "должен уметь". Каждый суслик - агроном. За этим проглядывает желание переложить всю работу на исполнителей.
gecube
14.04.2022 17:45значит, у нас должен быть точно такой же стандарт на врачей. Не врач-уролог, врач-терапевт, врач-хирург и прочие, а просто "мед сестра", "старшая мед сестра", "младший врач", "regular врач", "старший врач", "ведущий врач", "главный врач". И никаких специализаций
Vezyk
14.04.2022 18:05Года с 2004 или 5го не интересовался и не следил за изменениями, но насколько помню, в той области приоритетнее были документы в рамках орг-ции с названиями "должностная инструкция/обязанности, штатное расписание" и тп, в которых прописывались любые нюансы, например - запрет подходить к серверу ближе 1 метра тк на должность инженер-программист оформлялись, чуть ли не уборщицы, а в рамках ИТ отдела набор должностей регламентирован. Я это к тому, что формализм и реальность даже в тех рамках стыковались, хоть и смешным образом.
vconst
12.04.2022 04:21+5Автор совсем не в курсе такой специальности как "менеджмент"?
vics001
13.04.2022 11:39Менеджер не должен разбираться в программировании, а программист принимает кучу низовых решений, которые сказываются на продукте - какой минимальный API телефона поддерживать, какой API выбрать для работы с камерой, что делать при возникновении Exception, как поддерживать или не поддерживать ночную тему аппарата...
Le0Wolf
13.04.2022 14:20Минимальный апи неразрывно связан с версией ОС, что в свою очередь связано с охватил аудитории. Такие вещи - чуть ли не самая важная часть любого нормального ТЗ
Про исключения вообще можно целый раздел писать - реакция приложения на ошибки
Ну и все остальное, если не вдаваться именно в техническую реализацию (код) тоже вполне себе понятно любому менеджеру и больше того, он обязан знать такие нюансы просто даже хотя бы из опыта реализации проектов. Это если мы конечно про менеджера проекта говорим
vconst
14.04.2022 02:19+1Хороший менеджер - ессно должен разбираться в программировании, лучше менеджеры получаются из программистов
В составлении ТЗ, точно также ессно - должен участвовать и тот, кто в разбирается в программировании. Но не кодер, а кто-то уровня тимлида, который, по сути - тоже есть менеджер
AlexTroshkin
12.04.2022 05:08Да вот знаете, ничего один другому не должен. Может заказчик заплатит хотя бы раз в 100 больше что бы за него на родном языке изложили что же все таки он хочет в итоге, а может за него еще и подумать надо? Можно конечно win-win о чем все говорят, но кажется, что то не так :D
maldalik
12.04.2022 05:14+11Извините, а бизнес-аналитики, менеджеры там всякие, они для чего нужны? Если всем этим должен заниматься программист.
ZloyGremlinJE
12.04.2022 14:20+2Если бизнес-аналитик может немного в код, а разработчик немного в бизнес-аналитику(по крайней мере его не тошнит от предметки) , то разработка ускоряется в разы. Проверено на собственном опыте)
lenferer
12.04.2022 05:23+7Статья скорее показывает взаимоотношения между заказчиком и программистом на фриланс бирже, в нормальных компаниях уже давно есть аналитики и менеджеры которые и выясняют все требования и все уточняют.
siziyman
12.04.2022 11:11+1Я искренне не верю, что при разработке сложного продукта, а не очередного банкокруда по шаблону, аналитики и менеджеры в состоянии покрыть вопрос так, чтобы программист мог не глядя брать и делать. Очень много технических мелочей бывает, в которые они не погружены, и программисту надо вникать в детали, уточнять их, в какой-то момент ещё и зачастую предлагать возможные трейд-оффы ("вот эту фичу мы или будем делать 3 месяца вместо 1, или мы сделаем только 50% из заявленных возможнстей, но за 3 недели, или же мы сделаем фичу за полтора, но это затронет аспекты X и Y продукта").
0x131315
13.04.2022 20:03Так и есть. Но минимально проработанное ТЗ при этом быть обязано, чтобы как минимум до исполнителя донести суть проблемы и желаемое решение, причем понятным для исполнителя языком, с учетом того что исполнители могут быть далеки от бизнеса и его потребностей. Это если команды совсем маленькие, и в роли архитектора сам исполнитель выступает. Но нужно понимать последствия: таких архитекторов в итоге на проекте 70%, все разного уровня, зачастую без понимания предметной области и проблем бизнеса, что там они напроектируют страшно представить, для этого и нужно централизованное управление, один ответственный за архитектуру или аналитику. Разгребать последствия через пару-тройку лет заказчику за свой счет предстоит, так что это не экономия на архитекторе и аналитиках, это попытка отсрочить расплату за ошибки.
vics001
13.04.2022 11:41+1К сожалению все зависит от уровня программиста, один пишет, что при повороте телефона сразу креш, а второй пишет, что и ночная тема и для слабовидящих все сразу работает. На трудозатраты обычно это мало влияет, просто профессионал знает как делать сразу быстро и правильно.
0x131315
13.04.2022 20:08Это уже опыт. Но опыт стоит дорого - большинство задач решают джуны, они дешевле. Платить за опыт мало кто хочет.
agoncharov
12.04.2022 06:30+5А имеете ли вы моральное право задавать такие вопросы?
Да, после того как ТЗ и сумма оплаты утверждены — имею полное моральное право. Просто так я никому ничего не должен. Какие-то древние ГОСТы по разработке ПО никакого отношения к бизнесу не имеют и ни к чему меня не обязывают
YDR
12.04.2022 09:34Кстати, да. Суть статьи свелась к тому, что "Не участвуешь в составлении ТЗ -> не имеешь права называться ведущим программистом по ГОСТ"
Я недавно пробовал сделать устройство лучше ТЗ, (в написании ТЗ участвовал, но тогда еще было непонятно, что вообще получится) - мне сказали, чтобы не тратил время.
С другой стороны, понимаю, что бесконечные улучшения занимают бесконечное время, но принесут конечную пользу. Поэтому я пока в раздумьях.
Статье помогли бы несколько жизненных примеров.
kwaskoff
13.04.2022 15:01+1для проверки бизнес-гипотезы - не нужны никакие улучшения, так что не разумывай, делай то - что прописано в ТЗ. Все улучшения предлагай, но не делай без одобрения
Artem_7
12.04.2022 06:47+7А вот меня в институте учили (еще в 90-ые!!!), что ТЗ пишет исполнитель на основе тех. требований от заказчика. Т.е. этапы такие:
Тех. требования. Пишет заказчик. Отвечают на вопрос "чего надо?"
ТЗ. Пишет исполнитель. Отвечают на вопрос "Как поняли и что будем делать?". Утверждаются заказчиком
Тех. проект. Пишет исполнитель по факту выполнения работ. Отвечают на вопрос "Что в итоге сделали?"
По градациям программистов я согласен. А то сейчас, куда не плюнь, - все ведущие-сеньоры. Но мало кто понимает, какую задачу бизнеса решают их творения. Т.е. код-то качественный, но делает не то, что хотел заказчик...
RegisterClassEx
12.04.2022 11:27Вероятнее всего, Вас учили под влиянием советских ГОСТов. А советские ГОСТы написаны для организаций, минимум - для сторон договора, Поэтому брать на работе кодера и тыкать ему в лицо ЕСПД с порядком разработки ПО - глупость. Возьмите этот ЕСПД и ткните в директора, пусть выделяет людей для составления ТЗ и этого всего.
Более того, если не ошибаюсь, составление ТЗ - отдельный этап разработки, и оплачивается отдельно. Апосле утверждения заказчиком ТЗ он находится в большой зависимости от разработчика, т.к. ТЗ писал разработчик, а заказчик наверняка захочет это ТЗ поменять.
Опять же, ГОСТ сильно устарел, а методология разработки сильно продвинулась.
Kanut
12.04.2022 11:34+1Ну меня учили не в России и уж точно не под влиянием советских ГОСТов. Но почему-то учили примерно тому же самому. Да и если посмотреть на реальность, то это самое ТЗ, по которому потом работают программисты и по которому потом принимают результат, обычно заказчик в одиночку не составляет.
То есть это либо заказчик совместно с исполнителем. Либо его делает исполнитель и отправляет заказчику на подтверждение.
RegisterClassEx
13.04.2022 19:09Видите ли в чем дело... В Вашем комментарии фигурирует заказчик, исполнитель и программистЫ. Автор же утверждает, что "настоящий программист" сам ТЗ составляет. Ещё этот "настоящий" проводит бизнес-анализ, системный анализ, строит архитектуру, кодит, тестирует, сдаёт. Такой весёлый у нас профстандарт. В целом я не против, но всё зависит от размера проекта. На маленький проект, если хотите сэкономить, проект ТЗ лучше подготовить для программиста. На большом нанимать одного кодера или только кодеров, да ещё и заставлять их писать ТЗ - идиотизм.
Kanut
13.04.2022 19:14Понимаете, если у вас на проекте несколько кодеров, но при этом один из них участвует в составлении ТЗ, а остальные нет, то скорее всего этот один будет получать из-за этого большую зарплату. И я не знаю как у вас, а у нас в этом деле всегда участвует кто-то с "техническим бэкграундом". Обычно кто-то из кодеров.
0x131315
13.04.2022 20:13Обычно этим занимаются самые опытные из команды, с достаточным уровнем экспертизы. Как минимум консультируют аналитика и валидируют ТЗ, чтобы там не было откровенной чуши. Но это есть далеко не везде. Впрочем даже ТЗ не везде есть, и это плохо.
panzerfaust
12.04.2022 07:25+11Все так. И зачастую даже несмотря на наличие батальона менеджеров и аналитиков оказывается, что проект понимают тимлид и пара сеньоров. Они же и способны за одну встречу разрулить новые требования заказчика. А остальные для мебели.
Более того, взгляды некоторых крупнейших компаний напрямую предполагают, что разраб должен быть строго изолирован от кухни сбора требований и составления тз. Для этого они нанимают 22-летних девочек "аналитиков". На деле оказывается, что название их должности происходит вовсе не от слова ἀνάλυσις, а от другого похожего. Постоянная война с этими буратинами может так утомить разраба, что он реально придет в состояние "нет в тз - нет в коде" - даже есть с его квалификацией все в порядке.
Мы привыкли слышать жалобы на дефицит кодеров. Так вот дефицит хороших аналитиков (который от слова ἀνάλυσις) раз в 10 жестче.
gecube
12.04.2022 08:40+3поддержу, но есть еще целая каста аналитиков, которые адекватные и хорошие и помогают разработчикам, чтобы они не отвлекались на бессмысленную возьму и коммуникацию с заказчиком внутри энтерпрайза, потому что у этих ребят зачастую 7 пятниц на неделе. И это очень утомительно объяснять, что вот это мы делать не будем, это невозможно, а можно сделать только это и только за много денег. И для этого необязательно, чтобы "аналитик был хороший" или "отличный". Но хотя бы был с мозгами. Тут уж скорее архитекторы самые бесполезные люди - которые и умеют только рисовать схемки по тогафу, а в реальности система работает совсем по-другому. На самом деле я видел и нормальных Архитекторов, но кажется, что их еще меньше, чем толковых аналитиков.
13werwolf13
12.04.2022 07:33+7Тем не менее, если вы хотя бы чуть-чуть поменяете свое мнение в сторону большей клиентоориентированности, то сможете понять, о чем я.
уважаемые коллеги пограмисты, услыште меня:
Не надо перегибать палку в клиентоориентированности, от этого страдает и качество ваших продуктов. в банковских приложениях появились "сториз" из инсты, зато более важные кнопки "оплатить" "перевести" "пополнить" отошли на второй план. в мессенджерах половину функционала занимают смайлики, стикеры, гифки, звонки.. а в нормальное форматирование текста кроме телеги и матрикса никто не умеет. повсеместный переход на CSD и электрон, запихивание в web того чему лучше быть нативным, в половине софта отсутствует как класс интеграция с другим подобным софтом (даже импорт и экспорт уже мало кто делает).
если клиент предлагает сделать ху**ю не стесняйтесь ему это сказать и главное объяснить. опыт подсказывает что если клиент вменяемый то с ним можно вести диалог, а если невменяемый то учше с ним не иметь дел ни за какие деньги.
возможно за этот крик души меня заминусуют, так что просьба к тем кто уже потянулся жмакать "минус" не полениться и написать чому собсна минус.
dimskiy
12.04.2022 08:22+3Взгляните на это иначе: если сториз в банк-клиенте не нравятся вам, то совершенно не факт что они так же не зашли 80% не технической аудитории банка. Заказчик все же ближе к пользователю чем вы
13werwolf13
12.04.2022 08:28+1у меня есть смутное предположение что тут как раз "пипл хавает"
добавили сториз, радуются. добавили бы вместо сториз что-то полезное тоже бы радовались..
0x131315
13.04.2022 20:19За всякие соцплюшки и новые тренды отвечает не разработка, а маркетинг и менеджмент, те кто заказывают вечеринку, а не те кто ее организует. Как собственно и за развитие продукта в целом. У разработки тут инициативы почти нет, у них есть только ТЗ на эти все плюшки. Такова потребность бизнеса, именно за удовлетворение этой потребности разработке платят.
13werwolf13
13.04.2022 20:22Весьма спорный момент. С одной стороны решение принимают манагеры а программисты молча пилят, с другой стороны если бы все программисты хотя бы пытались объяснить манагерами почему делать гавно вместо софта - плохая идея манагеры бы возможно начали думать головой а не тем чем сейчас.
Spaceoddity
12.04.2022 08:02+5Опять абстрактно-пафосное "программист должен решать задачи бизнеса, а не писать код"?
Те критерии, которые вы описали больше напоминают "мистера Вульфа" из "Криминального чтива". Если вы хотите чтобы программист в одно лицо решал все проблемы вашего бизнеса, то прежде всего ответьте себе на вопрос - а готовы ли вы ему заплатить гонорар уровня топового кризис-менеджера?
dimskiy
12.04.2022 08:17+1Идея, конечно же, верная. Но не понятно при чем тут минтруд и почему его мнение должно както качественно влиять на мою работу.
А все что вы описали можно свести к клиентоориентированности + навыкам коммуникации. Если хотеть сделать работу так, чтобы клиент не чувствовал себя обманутым, то не нужны будут никакие формалистики от министерств
randomsimplenumber
12.04.2022 09:28Много букв про то, что должен делать программист, и ни слова про то, что должен делать заказчик.
Kanut
12.04.2022 09:30Может быть это так потому что хабр это ресурс для программистов, а не для заказчиков? :)
oq0po
12.04.2022 11:42В 34-м ГОСТе программисты вообще не упоминаются. Там упоминаются разработчики и программы.
Погромист - это один из видов разработчиков ( как, например, технолог).
Виды специалистов , необходимых для конктретной разработки определяются на этапе обследования объекта автоматизации и разработки ТЗ на эскизный проект. Вполне возможно, что достаточно купить готовый продукт, настроить его и переучить персонал ( или перестроить бизнес-процессы) , чем мутить новую разработку. Этим занимаются бизнес-аналитики, инженеры по применению ( методисты) и системные архитекторы.
OksikOneC
12.04.2022 09:29+5Автор, за статью Вам, конечно, спасибо. Допускаю, что именно в вашей предметной области, действительно нужно оценить критическим взглятом ТЗ, и возможно, подвергнуть сомнению те вещи в нём, которые показались странноватыми или неправильными. Но есть и другие миры - один из низ мир регламентного учета. Это вот то, где вы слышите такие термины как "НДС", "Налог на прибыль", "Распределение косвенных расходов", "Как двадцатку закрыть на сорок третий" и т.д. Может быть слышали про такое? Да, все это считается в каком-то софте и кто-то это тоже пишет :) И вот в этом мире - следование БУКВЕ (капс и болд здесь не случаен) ТЗ - ваша страховка в протоколе допросов по повестке. Потому что если в результате вашего "творческого осмысления" ТЗ, в котором было четко указано, что можно брать в качестве вычета по НДС, а что нет - получилось нечто иное, то разговор лично с Вами, поверьте - будет очень короткий. Если вы накодите по ТЗ, и в нем будет ошибка, в результате чего какой-то ваш клиент, или ваше предприятие, не доплатит того же НДС, либо налога на прибыль - как вы думаете, когда эту нитку раскрутят, к кому будут вопросы? К тому кто писал к ТЗ или к тому, кто его реализовал? Да-да, я в курсе, что когда практически в любом таком софте, при начале использования, вы соглашаетесь на то, что он поставляется как есть, и производитель не отвечает за любые издержки, вызванные некорретной работой оного. Такое есть. Но есть и обратное - законные требования контролирующих органов пояснить правильность расчета того или иного регламентного показателя. И если так окажется, что вы, накодя это, отошли от ТЗ, и результат вашей работы - требование от ФНС, или какого-то другого органа, то даже в вашей компании (интеграторе и т.д.) лично к вам будут вопросы от коллег, руководства. И примерно они будут звучать так:\
- Чувак, мы тебе платим деньги не за то, чтобы ты отклонялся от ТЗ. ТЗ, как и другие проектные документы - результат работы каких-то других людей. Аналитиков, методологов, возможно даже консульнатов. Вот они все, поработали, все согласовали. А ты, творчески не поняв суть, внезапно что-то там сознательно изменил. У клиента, кому мы это делали, теперь проблемы. А что будет, если ему сейчас минимум насчитают пеней и штрафов? Из чьей зарплаты это нужно вычесть? Из твоей? А ты уверен, что ее хватит?...ну и т.д.
Т.е. в сухом остатке, Автор, обращаясь к Вам, именно как Автору, резюмирую: где-то, вполне допускаю, что ваш подход допустим и даже полезен. Но где-то - это сулит вам проблемы, о которых Вы ранее, допускаю, даже не слышали, что у разработчика - они в принципе могут быть. Один раз вы обожжетесь на этом, и далее ваш поведенченский паттерн будет такой: если в ТЗ указано: 2+2=5, значит 2+2=5. Без вариантов. Т.к. возможно есть какая-нибудь 28/3 Глава НК, в статье 389 части 20 параграфа 8, в третьем предложении сверху, в варианте трактовки какого-то законодательного или исполнительного органа, и правда 2+2 = 5 для целей какого-то учета. Вы не знаете, правда это так или нет - но допускаете, что это правда так, и кодите спокойно себе это. И в случае любых предъяв с любой стороны, вы - лично Вы, в домике и не при делах. Вы можете возразить - да что за дела то? Не может быть такого! Ну и далее по логике вашей статьи. Повторюсь только: если Вам лично про это неизвестно, и Вас пока это все миновало - это не более чем Ваш опыт :)
Удачи в проектах!
Kanut
12.04.2022 09:32И вот в этом мире — следование БУКВЕ (капс и болд здесь не случаен) ТЗ — ваша страховка в протоколе допросов по повестке. Потому что если в результате вашего "творческого осмысления" ТЗ, в котором было четко указано, что можно брать в качестве вычета по НДС, а что нет — получилось нечто иное, то разговор лично с Вами, поверьте — будет очень короткий. Если вы накодите по ТЗ, и в нем будет ошибка, в результате чего какой-то ваш клиент, или ваше предприятие, не доплатит того же НДС, либо налога на прибыль — как вы думаете, когда эту нитку раскрутят, к кому будут вопросы? К тому кто писал к ТЗ или к тому, кто его реализовал?
Ну так а кто вам мешает указать заказчику что ТЗ кривое и потом исправить его вместе с заказчиком? Ну вместо того чтобы писать заведомо неправильно работающий софт?
randomsimplenumber
12.04.2022 09:50Если заказчик вместе с бизнес-аналитиком требуют использовать формулу 2*2=5 - роль программиста, в первую очередь, уметь сделать, чтобы случайно не получилось 2*2=4.99999. А так эта кроличья нора (до какого уровня погружаться в предметную и смежные области) очень глубокая.
Kanut
12.04.2022 09:52+2Ну так вас никто и не заставляет лезть в нору до упора. Но в статье речь идёт что человек, который просто сделает с "2*2=5" будет зарабатывать меньше чем человек, который хотя бы сначала уточнит нет ли ошибки в ТЗ.
И тут я с автором статьи полностью согласен.
OksikOneC
12.04.2022 09:52+5а кто вам мешает указать заказчику что ТЗ кривое...Ну вместо того чтобы писать заведомо неправильно работающий софт?
Для того, чтобы понять "кривое ли ТЗ" или нет, в части регламентного учета, вы должны уметь во всякие НК, ПБУ, ФСБУ и прочее, на уровне человека с ходу отвечающее на вопросы в каком разъяснении и кого, как трактуется та или иная норма. Ммм...Мне кажется, на уровне разработчика - это не просто овер скилл, это уже сверх овер скилл, и если Вы таким скилом обладаете - не понятно, зачем Вы кодите? Ну т.е., часто (или всегда) вы понятие не имеете "кривое ли ТЗ" или "прямое". Если там поработали аналитики, методологи, консультанты и оно подписано с обоих сторон - самое разумное и правильное для вас - следовать его букве. Вы, естественно, имеете право подвергать любой пункт, любое утверждение - сомнению, но чем больше вы будете кодить подобного - тем меньше сомнений у вас будет появляться. В конце, вы прийдете к простой аксиоме, из моего кейса выше: 2+2 = 5. И это, кстати, может и действительно быть таковым в какой-то части чего-то там.
Так что, отвечая на ваш вопрос про кривизну - да ничто не мешает. Просто подвергнуть сомнению ТЗ в таком ключе - это значит погрузить во все это нормативно-справочное, законотворческое и разъяснительное пояснилово. Но на то уже есть соответствующие люди, и они, априори, и написали для вас это ТЗ, перемолов всё это для вас и за вас - а вам осталось только накодить. И софт в этом случае, не заведомо неправильный. Просто вы не погрузились в эту глубину настолько, чтобы понять, что все таки, он правильный :)
Kanut
12.04.2022 09:54Ну так если вы не в состоянии понять что ТЗ кривое, то это одно. И никто от программиста не требует полного понимания предметной области.
Но вот если вы видите что ТЗ кривое, но при этом молчите и делаете по ТЗ… Зачем так делать?
randomsimplenumber
12.04.2022 10:10+2Но вот если вы видите что ТЗ кривое, но при этом молчите и делаете по ТЗ… Зачем так делать?
Строители молча вышли из чата.
ptica_filin
12.04.2022 10:48+1- Чувак, мы тебе платим деньги не за то, чтобы ты отклонялся от ТЗ. ТЗ, как и другие проектные документы - результат работы каких-то других людей.
Все люди ошибаются. Задача исполнителя, если он нашёл в ТЗ что-то странное, как минимум уточнить у заказчика, точно ли он хотел именно этого. Я не программист, а инженер. Но в большинстве случаев из моего опыта, когда в ТЗ находились странные вещи, они были именно ошибками. Что-нибудь недосмотрели, скопипастили не глядя, просто опечатка в цифрах и т.д. И только иногда заказчику осознанно было нужно именно вот такое странное.
OksikOneC
12.04.2022 12:59+6Я не программист, а инженер.
Хорошо. Я поясню на конкретном примере, как у нас, в кроваво-слезном финансово-регламентном интерпрайзе обстоят дела с разработкой. От клиента прилетает такая постановка: мы ведем учет в софте Y и у нас есть в поле завод с производственными цехами. Мы возим туда рабочих на вахту на автобусах. Затраты на ГСМ этого автобуса - как можно принять в расходах эту затрату в части касающейся? Помогите "настроить"!.
Эта поставка уходит к методологу по НУ (Налоговому Учету). Это такой чувак, который знает примерно по пунктам и главам НК (Налоговый Кодекс). Его результатом работы будет развернутый ответ с выдержками глав НК, писем минфина, решений судов и пр. и пр. От его ответа будет зависеть первая часть вопроса клиента - так можно принять эти затраты в расходы или нет? Методолог, с полным нормативно-справочным обоснованием, указанным выше - отвечает, окей. Можно!
Далее, этот апрув уходит к аналитику/консультанту/бизнес-аналитику.Это такой чувак, который получив однозначный ответ от методолога, уже определяет как конкретно в клиентском софте Y, настроить этот бизнес-процесс. Он подробно отвечает на вопрос - как это делать, что настроить, что где включить, как внести и т.д. Сам аналитик/консультант не обязан знать ответ на вопрос - можем или не можем, но точно обязан этот ответ прочекинить в софте и показать как это делается. Если выясняется, что это сделать нельзя (просто нет такого функционала, новый закон, изменения и т.д.), а клиенту - нужно, он описывает ФР (функциональный разрыв), пишет под него некие функциональные требования.
Методолог и аналитики/консультанты входят в функциональную группу в проекте. И все функциональное проектирование делает как правило аналитик/консультант. Но оно к технической части никакого отношение не имеет, как там на архитектуру все сложится в итоге, это уже хлеб других людей: технических архитекторов, тим лидов, и т.д. В результате, до разработчика (программиста) свалится уже готовое техническое (частное) задание на разработку, в котором учтено результаты функционального проектирования и технического. И все что ему остается, это сесть - и это все разработать (написать). И вот и в статье, и в вашем комментарии, отмечается что в финальном задании для разработчика могут быть какие-то ошибки, которые он сам может заметить, ну и как-то на это повлиять. Действительно, такое может, сугубо в его технической части, если тим лид, архитектор, технический рп и тому подобное, просто упустил что-то в части архитектуры (ну или тупо просто не прав/не знает тонкостей). Конечно, именно в данном конкретном случае, разработчик, действительно обязан сообщить о косячке и дождаться, когда это изменение протащится и согласуется во всех проектных доках. Это разговор один. Но он совершенно другой уже, когда разработчик сообщает о косячке не в техническом проекте, а в функциональном. Это буквально означает то, что вся вертикаль в части функционального проектирования полностью провафлила что-то, и скорее всего, даже согласовала с заказчиком, получило его утверждение. Ну т.е. это что-то из ряда вон вообще выходящее, и если разработчик может на таком уровне в регл.учете ловить такие косяки - то первый и самый главный вопрос, почему этот человек до сих пор пишет код? Очевидно, что он это уже все перерос, и ему надо двигать выше. Но по своему личному опыту, по опыту коллег, такие продвинутые в предметке разрабы, если и встречаются в дикой природе, то это однозначно очень краснокнижные экземляры. Просто сами прикиньте, сколько и какого опыта у вас должно быть вне технической разработке, чтобы ловить методологов/консультантов на их ошибках? Это совершенный овер-скил. В нашей отрасли, думаю такое могло бы быть, если разработчик сидел на одном виде учета лет 10, и разрабатывал подобное несколько раз для разных клиентов в разных отраслях. Но в жизни, такое если и встречается, то очень редко. Сам кроваво-слезный проектный регламентный интерпайз, вам, как разработчику, не сильно даст время на что-то более, чем разработку по заданиям. И у вас всегда есть выбор - вы либо держите сроки (более или менее), а на это тратится все рабочее время, либо - вы барахтаетесь в предметке, пытаясь там что-то для себя пояснить. Это отлично, но надо понимать, что скорее всего - вы это будете делать за свой счет в нерабочее время, выходные/праздничные дни. А оно вам надо? Может кому и надо, но таких меньшинство. А в рабочее время, вы только будете таски в жирах закрывать. Там особо нет времени на раскачку.
Много написал, но думаю главную мысль донес. Вот это и есть кровь интерпрайза. Разработчик в нем - это чисто мозги и руки именно для разработки. Все проектирование делается за вас, для вас, чтобы вы могли сосредоточиться именно на разработке как таковой. Вам буквально за предметку вообще не надо переживать - главное в сроки с должным (более или менее) качеством реализовывать эти задание в коде. Как-то так.
Я так понимаю, Автор статьи, как-то этот момент не учел в своем повествовании :)
SpecPortal Автор
12.04.2022 14:03+1Спасибо за столь развернутый комментарий. Очень приятно видеть аргументированные позиции. Автор статьи в полной мере это учел, потому как разбирается в НУ, БУ, УУ, ПБУ и прочих "У". Позиция автора состоит в том, что любой предметной области можно научиться коль скоро ты за нее взялся. "Научиться" в данном контексте означает разобраться настолько, чтобы решить задачу методологически правильно (хорошо) и подсказать заказчику, что можно сделать лучше, чем он заказывал (идеально). Не так страшен черт как его малюют - автору в свое время приходилось разбираться в раздельном учете НДС, тонкостях учета растаможки товаров и прочих около ГТД-шных вещах и во многом чем еще. И ничего! - будучи программистом и не имея под рукой специально обученных людей, готовых подать тебе информацию на блюдечке, автор с этим разобрался в приемлемые для заказчиков сроки. Да, нужно уметь искать информацию, но благо заказчики всегда идут на контакт в этом и готовы общаться с тобой бесконечно долго, лишь бы ты их понял. Да и программист, по сути своей, человек интеллектуального труда (если он не техник) - залезть в консультант+, пообщаться с рабочими в цеху всегда сможет.
Отдельно подчеркну, что это ни в коем случае не исключает из проектов таких людей как аналитиков, методистов, архитекторов и других людей.
Проблема, затронутая в статье, это больше про инертность и закостенелость в позиции "Я - программист, дайте ТЗ". Такая монументальность останавливает тебя в развитии. Ты можешь быть сколь угодно крут в технологиях и "стеках", но если ты не можешь понять заказчика, то ты неизбежно проигрываешь своим коллегам.
В моей статье речь идет о развитии, об образе мышления, о том как стать лучше и самодостаточнее - приносить больше пользы людям!
YDR
12.04.2022 15:54Если программисту что-то непонятно, пусть переспросит лишний раз.
Вышестоящим этот его вопрос тоже может оказаться полезным, я как-то придумал нечто новое, когда объяснял проблему водителю.
DmitryMurinov
12.04.2022 16:17+1"Ну т.е. это что-то из ряда вон вообще выходящее, и если разработчик может на таком уровне в регл.учете ловить такие косяки - то первый и самый главный вопрос, почему этот человек до сих пор пишет код? Очевидно, что он это уже все перерос, и ему надо двигать выше. "
Частный вариант ответа. Потому что разработчик с уровнем сеньора и конкурентной зарплатой не является наивным идиотом. И понимает что за +70К...+150К к зарплате получит кучу нервотрёпки, гораздо большие риски сесть по УК (в том числе из-за подстав/при смене собственника) и ускоренную деградация в профессии, которую осваивал n лет. Если здесь правительство чем-нибудь окончательно его удивит, как разработчик он может подать заявление на визу и переехать в возрасте до 55 лет включительно в целый ряд стран. А как руководитель, скорее всего, нет.
ptica_filin
12.04.2022 16:56Ну в принципе, я сразу это понял, не стоило так развёрнуто отвечать :)
Наверное, очень удобно работать в большой конторе, где каждый занимается только своим делом и на своей позиции настолько компетентен, что никогда не ошибается. А если накосячил, то его косяк где-то там отловит кто-нибудь другой. Где-то там сверху должны быть ребята, которым виднее. И если решили, что 2*2=6, то не кодера это дело. Не по его зарплате вопрос, и провались оно всё :)Главное, чтобы когда оно таки провалится, кодера не сделали крайним. Как оно в кровавом энтерпрайзе с этим?
В мелкой фирме вертикаль гораздо короче, и я, как начальник отдела, уже сам являюсь её частью. Надо мной только руководитель проекта, а подо мной только непосредственный исполнитель. А то и я сам исполнитель.OksikOneC
12.04.2022 21:55Главное, чтобы когда оно таки провалится, кодера не сделали крайним. Как оно в кровавом энтерпрайзе с этим?
Специфика регламентного кровавого интепрайза в том, что там когда что-то "валится", то как правило клиент про это узнает только после того, когда ему приходит какое-то требование, либо аудиторы дали не очень позитивное заключение и подсветили какую-то проблему, которое "уже почти" требование. Т.е., когда посыпалось - боржоми пить в прямом смысле, поздновато.
А может и совсем поздно, в случае короно-кризисных выходных рабочих праздничных оплачиваемо-неоплачиваемых дней. Там вообще такие истории были: увольняют по сокращению, делают выплату. Человеки ушли. Сотрудников много, расчетчик в запарах не проверил полный расчет, а может и не знал как в текущих реалиях проверить. В любом случае, выясняется что некоторым бывшим переплата составляет где x2, где x3 от положенного. Соответственно, организация обращается к бывшим сотрудникам - дескать, ошибочка вышла, вертие ошибочно перечисленные. А те такие - чеееего? Давайте в суд, вы нас в короно-кризис вышвырнули на улицу, мы считаем - это компенсация. Соотв., в суде, судья у организации спрашивает - на каком основании вы сделали эти завышенные выплаты, привидите АЛГОРИТМ расчета вашего ПО на данных этих сотрудников. И далее начинает раскручиваться эта нитка - а это не мы писали, нам подрядчик писал, вот наши подписанные акты, вот наше задание, а сами мы не местные. Далее, несмотря на то, что в договоре с подрядчиком, естественно указано, что дефекты, в т.ч. и скрытые, ущерб и бла-бла-бла, не может быть предъявлен и все такое - может потребоваться экспертиза, что и кто накодил. на основании чего, а дальше дальнейшие суды и попытка истребовать клиентом компенсацию уже с подрядчика. Т.е. в этом кейсе, именно этом, конечно не думаю что подрядчик сам будет судиться со своим сотрудником в ключе - кто не так ТЗ понял, но сами понимаете. Работу придется однозначно сменить, если это не технический косяк. Если же, претензии к вам, как к организации, имеет не ваш клиент, а другие - то вероятность сходить именно разрабу по повестке, прям не нулевая, т.к. я надеюсь вы понимаете, когда дело доходит до такого, крайним быть никто не хочет. И, естественно, здесь просто железобетонный аргумент такой, что разработчик писал по ТЗ. Т.е. 2+2 = 5, и ему это по барабану, т.к. в ТЗ так написано, а разраб - ни методолог, ни консультант, ни аналитик, ни ПМ, ни тех.лид и т.д. перечисляем, кто он "ни". К Вам, именно при такой постановке = вопросов ноль, при условии что эти задания будут предъявлены. Поэтому, от греха, только от греха подальше, лучше все бекапить :)
Penguinus2008
12.04.2022 09:41+4Как все весело придумали.
Чего бы не добавить в качества программиста, ну, допустим, умение пользоваться фотошопом и блендером каким-нибудь, дизайн накидать там, ну, пусть еще и в колористику может, а то что он за профессионал-то? До кучи, пусть еще и разбирается во всех предметных областях, а то приходит заказчик такой, магазин автоматизировать по продаже футболок, а программист - не знает как бухучет вести правильно, чего ж он такого там напрограммирует? О, хорошо бы и законы всех стран знать, ведь кто знает откуда будет заказчик, а накодит там чего-нибудь, а потом инспекция придет и по шапке надает.
Вот если этого минимума нет, то какой вы программист-то тогда? Проходимец с курсов какой-нибудь.
Да, а если найдется такой вот настоящий ведущий, то платить ему 80к рублей в месяц, а то программисты и так жируют, иначе откуда столько курсов-то?
Если по тону сообщения непонятно - это шуточка. Программист, внезапно, должен программировать. Выяснять что там хочет заказчик - задача менеджеров и аналитиков. Если программист на себя берет их обязанности, то с разделением труда в конторе не все в порядке.
iiwabor
12.04.2022 09:50+2Я как-то был в командировке на одном небольшом металлургическом заводе и там эффективные менеджеры сократили технолога(ему же платить надо!) и на координатно- растяжном прессе его функции взвалили на оператора-программиста.
Ненуачо - он же работает уже 7 лет, должен уже все знать лучше любого технолога, он же программист(а на зарплате новая обязанность не отразилась совсем), вот пусть и вкалывает, а не за компухтером своим кофе пьет! А то что сопромат не знает - ниче, научится.
Оператор попытался написать технологические карты, и по ним работать - ничего не получалось, конечно, потом плюнул и стал работать вручную - на глазок.
Брак на оборудовании был - 100%, но директор приказал службе ОТК принимать все - в сборочном цеху доработают напильником и кувалдой.
anaken
12.04.2022 09:55+1В современном мире разработки чаще применяется подход agile, в котором роль ТЗ выполняет userstory, которая описывает виденье нового функционала далекими от разработки людьми, после этого userstory прорабатывается и делится на уже конкретные мини-подзадачи аналитиками, либо тим-лидами, либо мини-собраниями команды разработки (планирование-грумминг). Таким образом процесс подготовки ТЗ разделен на этапы, минимизирующие риски в реализации и сроках.
pavelsc
12.04.2022 10:30+3Задача хорошего программиста убедить заказчика выкинуть из ТЗ на 300 часов какие-то пункты, сместить ползунок от customer first в сторону code first подхода, чтоб меньше плодить сущностей, уместить это в 100 часов, но все равно сказать, что конечно же займет 300 часов. В итоге мы получаем ситуацию win win - проект не перегружен, заказчик всегда получает то, что требует бизнес, сроки не срываются никогда. Конечно кодить по 6 часов в сутки уже не получится, но думаю остальное перевешивает
prefrontalCortex
12.04.2022 12:07+1нужно быть не просто человеком-печатной машинкой кода, а аналитиком.
Чтобы выдвигать такие требования, нужно раскошелиться на адекватную денежную компенсацию, а не как у нас, "конкурентная з/п 40 тыс. руб. в месяц".
siziyman
12.04.2022 12:25+2В РФ программист (по крайней мере до недавних событий) даже без руководительских обязанностей мог без проблем зарабатывать и 400+ в месяц, и это работая в штате вбелую по ТК, я молчу о вариантах с валютной удаленкой
Carburn
13.04.2022 15:24Конкурентная это 30к же. Так конечно, ведущим программистам не 40к платят, а больше. Это статья про то, что нужно уметь чтобы много зарабатывать
ComradePashka
12.04.2022 12:54Ох.. ну да, наверное, вот такие формалисты есть в чистом виде, конечно, но это еще и может быть профдеформацией. Это лучше всего проявляеься на всяких легаси проектах, когда заказчику нужно вот тут и сейчас что-то сделать/пофиксить и он слишком жадный, чтоб всю архитектуру серьезно отрефакторить, а это неизбежно приводит в последствии к "а вот тут еще давайте...", "а вот здесь давайте тоже поправим..." и т.п. только в его понимании это все часть исходной задачи. Ну и посредники. Хуже всего, когда они пытаются честно себя выдать за реального заказчика, но понимают в проекте приблизительно ничего.
В свои фрилансерские годы всегда уточнял детали и пытался вытянуть из клиентов даже больше информации, чем они давали. И иногда, в таких случаях, проект действительно затрагивал косвенные задачи, но в итоге все были более, чем довольны. Когда познакомился с канбан -- вообще стал вести там проекты, при этом подключая клиентов к тем же доскам с кратким обзором как это работает -- очень удобно.
Сейчас у меня в стартапе вообще все с юзерсториз, спринтами, ежедневными конфами, с канбаном и диаграммами Гантта, с блокировками межу командами и все в таком духе -- очень эффективно.
Не представляю как по ГОСТам минтруда это все вообще может работать (и работает ли хоть где-то?)
Virgo_Style
12.04.2022 13:36Эти многабуков можно было бы сильно сократить примерно до «Ну тебе чо, слабО, что ли? Ты чо — лох какой-то, что ли?»
На ком-то даже сработает.
askharitonov
12.04.2022 14:13Лучше конечно по возможности выяснять подробности, что и зачем делается. Однажды мне поставили задачу перенести данные между сильно различающимися конфигурациями 1С, я написал обработку, перенёс номенклатуру, цены, остатки, может даже приходные и расходные документы. Заказчик проверил и поставил следующую задачу: убрать из новой конфигурации старые операции, оставив только номенклатуру и цены... С тех пор я не очень люблю, когда задачу ставят по частям...
Но будет ли программист предлагать свои изменения в ТЗ, наверное в большой степени зависит от заказчика (работодателя). Как от личных качеств того, кто ставит задачи, так и от того, как там в целом выстроена система принятия решений.
Crafter2012
12.04.2022 16:04+8Знаете, что больше всего выдает в вас низкоквалифицированного программиста?
Субъективное деление программистов на квалифицированных и нет, и написание статьи по мотивам? ;)
kirillk0
12.04.2022 17:34+5Никто в здравом уме программистов ни до общения с клиентами, ни даже до чтения ТЗ, согласованного с клиентом, не допускает. Это отдельная профессия, аналитик называется.
Да даже в плане менеджмента как вы это себе представляете? ТЗ же оно слишком большое обычно, чтобы один программист в обозримые сроки его сделал. Типа закинули в комнату с программистами ТЗ, ушли и ожидаете, что оно всё чудесным образом сделается? Его надо как-то поделить на задачи. Тот, кто это делает, конечно должен очень хорошо понимать бизнес. А тот, кто потом делает эти задачи, понимать бизнес должен только в небольшой степени
MKMatriX
12.04.2022 17:58+7А зачем вообще платить менегеру, который переводит бизнес-требования в ТЗ, если донести до разработчика нужно бизнес требования?)
Может вам тогда нужен сразу программист-менегер, который услышав ваших хотелки, проведет кучу анализа и предоставит несколько путей решения, с точными сроками, стоимостью, возможными рисками. Можно заодно придумать план для вашего бизнеса на десятилетие вперед.
А вообще передавая разработчику ТЗ вы берете на себя ответственность, что выполнение этого ТЗ максимально дословно это и есть то что нужно бизнесу. Если вам нужны варианты и т.д. вам не к разработчикам, а к менегерам, это они может сами, а может беседуя с разработчиками могут выдать варианты.
А все остальное у вас это прикрытие бумажками одной простой хотелки, вы хотите сказать программисту "сделай хорошо". Не работает это по той простой причине, что у программиста есть очень много областей для развития помимо вашего драгоценного бизнеса. Он может туда влезть, возможно ему даже хватит смекалки сделать такой же забыв про программирование. Но он не станет. Программисты часто любят науку и абстрактные знания, поэтому вместо того чтобы изучать скучный вопрос "как мой бизнес зарабатывает деньги" он лучше почитает про новые технологии, открытия, физику, математику. Благо хватает бизнесов, которые понимают зачем человеку, отдавшему науке не один десяток лет, для общения с бизнесом нужен переводчик)
axmct
14.04.2022 12:06А зачем вообще платить менегеру, который переводит бизнес-требования в ТЗ, если донести до разработчика нужно бизнес требования?)
Может вам тогда нужен сразу программист-менегер, который услышав ваших хотелки, проведет кучу анализа и предоставит несколько путей решения, с точными сроками, стоимостью, возможными рисками.
Есть разные отрасли в IT, в том числе и именно такие. Когда нет ничего лучше чем чистые бизнес-требования с вариантами использования. Без каких-либо технических деталей, чистый UX.
К примеру ERP системы, где уместнее самому программисту создавать технический дизайн по ходу работы, и проактивно предлагать в том числе функционал. Но такая роль в индустрии только в обиходе называется программист, а более формально это технический консультант как к примеру Senior Development Consultant.
Вот тут классификация по канадскому NOC более уместная чем "программист", "программист плюс": https://habr.com/en/post/660339/#comment_24261811
alexfilus
13.04.2022 10:44Всё так если не брать в расчёт разработку по фикс прайсу. Есть и конторы и фрилансеры которые работают по такому принципу, и там если даже ты заметил что клиент хочет дичь, а чтобы сделать нормально нужно больше времени, то может быть себе дороже ему сообщать о проблеме.
ИМХО это отличная идея взять сеньора в штат и сказать ему "сделай хорошо", но не у всех есть на это деньги.Ndochp
13.04.2022 11:24Это надо адвоката сразу в команду включать, так как в большинстве случаев клиент перестает хотеть дичь, которая в ТЗ сразу, как видит её на экране. И искренне считает, что платил за решение, а не за дичь в ТЗ.
BellaLugoshi
13.04.2022 10:45+1Не согласен с автором статьи и как доказательство ролик с ютуба "Дубляж британской короткометражки "The Expert" - https://youtu.be/UoKlKx-3FcA
к несчастью ни одного заказчика, который бы не попадал в это видео - мне видеть не доводилось.
nmrulin
13.04.2022 11:15+1Всё -таки задачи бизнеса решает начальник программиста. Программист же не в вакууме работает. У него есть начальство, которое кстати говоря больше этого самого программиста получает. Как раз за то самое, чтобы задачи бизнеса согласовать с кодом. А вовсе не за то, чтобы просто передать вниз приказ вышестоящей инстанции.
shornikov
13.04.2022 12:00Программист, который работает за деньги а не за идею, ИМХО будет предлагать поправить ТЗ только в случае, если есть возможность сэкономить свои силы. Или там уж совсем лютая дичь, а к заказчику есть симпатия.
Ndochp
13.04.2022 14:22Так вовремя поправить тз — это сэкономить силы на сдачу работ.
shornikov
13.04.2022 15:18+1за поправить ТЗ вам не платят.
За поправить код - вам платят, более того, вы уже думали и может даже заложили фундамент для этих правок.
Ваше руководство (не всегда) тоже в плюсе. возьмут как за полноценную работу, а сделаем - за половину времени.
Я понимаю, что подход - такой себе. Не на уровне "насрем себе в штаны", но где-то рядом. Но если помогать всем бесплатно (решать за других их проблемы/обязанности), на штаны просто не хватит.
Ndochp
13.04.2022 16:19+1Заказчик (на моем большом опыте внешнего подрядчика) берет заголовок ТЗ типа "Система учета себестоимости надоя кур" и на ПСИ выясняется, что готовая система учитывает надой в литрах, а нужно яйца в штуках, значит принимать то что получилось у вас не будем, и пофиг, что там внутри ТЗ написано.
Antervis
13.04.2022 13:52+6Тезис: "вы плохой программист если просто следуете бумажке по пунктам". Доказательство: "смотрите, вот вам бумажка, в которой по пунктам написано что надо делать чтобы быть хорошим программистом". Ирония
Amtell
13.04.2022 14:27«нет в ТЗ – идите мимо»
Знайте, если вы так делаете, то вы низкоквалифицированный программист-техник, не больше!
Бывают случаи, когда приходит "одаренный заказчик" с крайне низким уровнем технической грамотности, и у меня закономерно появляется очень сильное желание побыть 5 минут низкоквалифицированным специалистом. И порой результаты этих 5 минут оказываются куда продуктивнее нежели 2 предыдущих часа разжевывания материала.
Но это частный случай. Статья интересная, однако написана с явным перегибом....
zetamen
13.04.2022 14:32Статья скорее про рост в профессии, а не про то, что все кодеры должны понимать желания бизнеса, но акценты расставлены криво.
CrocodileRed
13.04.2022 15:35+3В целом бред, так вы путаете управление , аналитику и разработку. Ваше правило работает если в процессе участвует два человека: заказчик и исполнитель. Но чем больше команда, тем больше необходима формализация и разделение обязанностей.
Kekushiftkey
13.04.2022 15:36+1прочитал. минтруд пытался в "различия джуна, миддла и сеньора" сферического программиста в вакууме
а там окажется, что как у врачей, у программистов есть направления, а у направлений есть свои компетенции.
Grigorenkovic
13.04.2022 16:15+2Понимание процессов на уровень выше, чем в ТЗ, не относится к программированию. К этому можно, и скорее всего нужно придти. Но говорить, что человек, который сделал все по ТЗ - некомпетентный и низкоквалифицированный, это неправильно. Некомпетентность проявили в данном случае заказчик и составитель ТЗ.
Ndochp
13.04.2022 16:26-2Если он не может ничего больше, то он не некомпетентный, а низко квалифицированный. АКА джун АКА техник-программист.
Mishima_Zaibatsu
13.04.2022 17:00+3А платят ли за проект по рейту высококвалифицированного специалиста, значительно выше рынка, с учётом его способностей к анализу бизнес-задач?
Ndochp
14.04.2022 09:05В статье затронут стандарт на джуна, мидла и сеньера как их видят в министерстве.
Соответственно, всем всегда платят по рынку.
Только техникам по рынку джунов
Ведущим — по рынку сеньеров.
Mishima_Zaibatsu
13.04.2022 16:54+2Вы до потертости пальцев будете тыкать в ТЗ, говорить, что оно утверждено и подписано заказчиком. Что он сам виноват в том, что не углядел/не дописал, а теперь топает ногами и требует, чтобы вы доделали работу, но никогда не признаетесь, в том, что не смогли здраво оценить свои силы, потому как некомпетентны.
Знайте, если вы так делаете, то вы низкоквалифицированный программист-техник, не больше!
Очень сильно это зависит от того, кто кому и сколько платит. И стоит ли оно того.
Одно дело - иметь долю (акции) в компании и быть прямо заинтересованным в её успехах. Или щедрое вознаграждение здесь и сейчас, желательно с прозрачными перспективами дальнейшего роста.
Совсем другое - просто делать свою конкретную работу за конкретную зарплату или контракт и не морочить себе голову не своими проблемами.
Будем честными, в IT - своя атмосфера. И айтишникам она предоставляет больше свободы, чем в других. Почему бы ею не пользоваться? Можно хоть обложиться ГОСТами, но почему-то не упоминают, что всё это стоит нервов, здоровья и сильно зависит от человеческого взаимопонимания. Иной раз проще уйти в другую компанию или найти другого заказчика, чем что-то кому-то доказывать.
kellas
13.04.2022 19:26+1Ну на хабре формалистов нет - https://habr.com/ru/post/340052
тут все знают что нужно заказчику без всяких там тз и фидбеков )
alex-1917
13.04.2022 20:11Когда ТС подписал ТЗ не глядя и его жестко нагнули, втуляет теперь бред какой-то.
mphys
13.04.2022 21:35+1Я инженер-конструктор, там где я работаю мы делаем ядерные реакторы, и мне очень близко всё то, о чем вы написали, только в разрезе конструкторской работы. Можно я возьму за основу ваш текст и перепишу его слово в слово, только в своём контексте?)
axmct
14.04.2022 01:29Знаете, что больше всего выдает в вас низкоквалифицированного программиста
Скорее просто определенный класс профессии. Computer programmers, а не software engineer или technical consultant. Явно ведь нельзя понятием программиста заменять множество ролей в индустрии.
Вот Канадский ГОСТ. National Occupational Classification (NOC).
217 - Computer and information systems professionals
2171 Information systems analysts and consultants
2172 Database analysts and data administrators
2173 Software engineers and designers
2174 Computer programmers and interactive media developers
Есть у них такое однако.
Assist in the collection and documentation of user requirementsAssist in the development of logical and physical specifications
2175 Web designers and developers
Я, к примеру, программирующий без ТЗ "Information systems consultant". Самый настоящий программист, точно не Zero code. Мне платят за то, что я пишу программный код который делает то что нужно бизнесу. И понимать бизнес-процессы эта роль просто обязана хотя бы на уровне junior функционального специалиста по системе ERP.
2171 - Information systems analysts and consultants
Confer with clients to identify and document requirements
Conduct business and technical studies
Design, develop, integrate, test and implement information systems business solutions
Provide advice on information systems strategy, policy, management, security and service delivery.
MakMS
14.04.2022 09:25+1статья не затрагивает один в наше время важнейший вопрос "А заказчик готов оплачивать работу ведущего программиста и решение всех задач, не вошедших в ТЗ?".
ТЗ - зона отвественности заказчика (всегда).
ТЗ - это едва ли не более 50% от успеха решения поставленной задачи.
Зачастую получаем ситуацию, в которой куча работников заказчика готовит вместо ТЗ "филькину грамоту", а потом возникает наезд "вы посредственный программист", "вы должны были поработать за нас". Так может программист должен работать за заказчика и заказчик должен оплачивать работу вместо выплаты зарплаты, давайте говорить открыто, дармоедам?
Один из моих УЧИТЕЛЕЙ рассказывал как такую ситуацию "разрулила" польская команда программистов и системщиков, когда по ходу работы по развертыванию MES и ERP на предприятии выяснилось, что помимо типовых задач они должны проанализировать все технологические и бизнес процессы, составить план поэтапного внедрения указанных систем и внедрить их безударно. ТЗ этого не предусматривало. Бюджет был зафиксирован, о его изменении заказчик разговарить отказался, более того еще и кидался фразами про некопетентность и т.п. Итог закономерен: на всех страницах и отчетах MES и ERP, которые не предусматривались ТЗ выходила фраза "jak płatne i jak to się robiа" (перевод сами найдете).
С момента внедрея указанных систем прошло 15 лет и год назад меня приглашали на их "модернизацию" (термин согласно очередного ТЗ). Так вот, до сих пор эта фраза выводится на экран и бумагу. И, судя по всему, будет выводится до полного сноса Систем, т.к. этот опциональный функционал заложен на уровне базовых модулей и приложений. Как вы уже догадались, в ТЗ нет ни одного слова о том, что необходимо не просто модернизировать Системы, а переписывать их с нуля (ну или править на уровне ассеблера, ведь исходников кода все равно нет).
F376
14.04.2022 09:30У статьи или у ее автора однобокий взгляд,
в котором программисты (и тем более, их квалификация) всенепременно связаны или должны быть связаны с "бизнесом".
Либо, подразумеватся всенепременное сущестование "заказчика" А это совсем не так.
Таким образом, ложна сама исходная посылка.
Примеры:
Квалификация программистов Open Source ПО.
Квалификация программистов DemoScene.
Квалификация программистов в институтах или заводских государственных КБ (создавших ПО для космической техники, например "Буран").
Ко всему прочему, имеются большие вопросы к понятию "квалификация программиста". Вот, например, товарищ "А", всю жизнь писавший текстовые парсеры-компиляторы, способный за день наваять вполне действующий язычок. Но ничего не понимающий в 3D с его матрицами, векторами, shading language и ассемблером. Посади его за 3D, он будет барахтаться пару недель. А может и вообще не выплыть. Вообще никак. То есть результат ноль. Таким образом, его производительность в несвойственной ему области снижена раз минимум в 15, а то и более. И это еще не считая того времени ккоторое он будет убивать на чтение дома (не в рабочее же время ему читать книжки и материалы). А вот товарищ "Б", всю жизнь ваявший 3D, способный запилить +- быструю сценку/3D редактор в режиме хакатона примерно за день. Посади его писать парсер-компилятор - и внезапно, минус тех же пары недель (если не больше) и все только ради того чтобы на выходе вышел корявенький-прекорявенький первый пробный шар. Со всеми вытекающими проблемами, шаг влево, шаг вправо -расстрелтребуется еще время. А может и снова, ничего не выйти (т.е. потребуется время x30...x60).
Налицо, производительность сниженная от ~15 раз по сравнению с первым. А вот третий товарищ "В", Embedded программист, двадцать пять лет шатавший электронику, FPGA и микроконтроллеры, имеющий понятие о схемотехнике и последствиях связи программного и физического (эл. процессов). Ни парсер языка, ни 3D не потянет. Ваяет на простом СИ, без ООП и функциональщины, паттернов и проч, о которых никогда не слышал. Но вот вопрос - если посадить первых двух, какая там "электроника" получится на выходе? И затянуться может также не x15, показатели x45...x60 легкодостижимы.
Так что "квалификация", это очень спорная вещь. Связывать с ней что попало я бы не советовал. А также по дуре считать что для решения некоторых задачи всегда всенепременно требуется сверхбог способный и в различные языки, и в ООП и в фукциональщину, и электронику, и математику, и инжиниринг, и сети, и linux OS-программирование, и культуру разработки, и проч, проч, проч.
Аналогично, инжиниринг ПО и менеджмент (процесса создания ПО) это разные вещи. Не надо их связывать. Хотя для срачегенерирующего кликбейтного заголовка-красной тряпки на что только не пойдут.
ChiDa
14.04.2022 09:33Лонгрид на тему выживания ремесленника а-ля компьютерная помощь. Давайте начнём с того, что высококвалифицированный программист занимается внезапно программированием. А вот все эти постановки задач,анализ бизнеса, дело команды продукт менеджера или фидбэк от отдела тестинга маркетинга и так далее, опять же пропущенные через менеджеров и нарезанные на спринты.
Kanut
14.04.2022 09:36+1Давайте начнём с того, что высококвалифицированный программист занимается внезапно программированием.
Так можно дойти и до того что программист на самом деле внезапно просто текст кода набирает и всё. И тогда он внезапно будет мало чем отличаться от машинистки....
agim-gal
Эту статью есть смысл читать, если ответы на 3 вопроса вначале "конечно же да"?
SpecPortal Автор
Не имеет смысла) Лучше оставьте свой телефончик - мы с вами свяжемся))
haldagan
Не серчайте если покажусь грубым, но не могли бы вы ответить на два вопроса:
1) На какую компенсацию может рассчитывать такой совсем-фулстек-погромист (с полным погружением в
заказчикапредметную область) у вас?2) Зачем вы нужны человеку, который и швец и жнец и на дуде игрец?
Или я неправильно понял и вы ищете исполнителя, а не сотрудника?
thatsme
Мало того, отсутствие квалифицированного менеджмента и аналитиков, пытаются заменить одним программистом. Т.е. явно, что с подобными конторами, можно связываться только, если уж совсем деваться некуда. Изумительные наглость и хамство ...
К этой цитате есть следующие замечания:
Грамотность (т.е. её отсутствие)
Неумение формулировать мысль.
Задачи бизнеса решает менеджмент, иногда используя программистов как ресурс. Неумение использовать ресурсы правильно, - стратегический (или тактический если подобное происходит редко) прокол менеджмента, а не программиста.
Никакую контору не спасёт супер-пупер-программист, если заказчик (в данном случае внутренний) сам не знает чего хочет, и когда догадывается, что чего-то хочет, то выразить это не в состоянии.
inscriptios
Все стороны правы, а все потому, что и Минтруд, и читатели почему-то возлагают на разработчика слишком много. До разработчика должны поработать бизнес-аналитик, системный аналитик, архитекторы, а уже потом разработчик может просто следовать ТЗ (почти). Но, о чем это я, так же не принято и вообще где найти всех этих людей, правда это уже другой вопрос.
А про заказчиков справедливо следующее шуточное (но в каждой шутке есть доля шутки) утверждение и его нужно принять: "Заказчик никогда не говорит чего он хочет, а хочет он всегда не то, что ему нужно".
0x131315
Самое прикольное, когда не то что тотально парализовано все управляющее звено, а даже никто не представляет как оно вообще работает: ни документации, ни карт процессов, ничего, либо все это только для внутреннего пользования, а программист обломится, он же джедай. ТЗ тогда идут уровня "сделай что-то, не знаю что, не знаю как, но чтобы работало как я придумал, но как придумал не расскажу". Реальная проблема часто до конечного разработчика даже не доносится, теряясь в пути. Такое себе.
vism
Вот у меня ответ на все вопросы тоже - да.
Только я давно работаю сам на себя, как и многие другие с таким ответом.
Т.к. люди отвечающие "да" на все эти вопросы, уже не просто программисты.
Это предприниматели-программисты, с должностями в которых присутствуют слова Архитектор, Консультант, Лид и соответствующей оплатой их труда.
И это всё вот к чему. Какую вы предлагаете месячную оплату? Просто ради интереса :)
themen2
А какие у вас ожидания? Обычно они так спрашивают
DrPass
А если ответы — «зависит от того, кто заказчик, и как выстроены с ним отношения»?