Comments 207
Эту статью есть смысл читать, если ответы на 3 вопроса вначале "конечно же да"?
Не имеет смысла) Лучше оставьте свой телефончик - мы с вами свяжемся))
Не серчайте если покажусь грубым, но не могли бы вы ответить на два вопроса:
1) На какую компенсацию может рассчитывать такой совсем-фулстек-погромист (с полным погружением в заказчика предметную область) у вас?
2) Зачем вы нужны человеку, который и швец и жнец и на дуде игрец?
Или я неправильно понял и вы ищете исполнителя, а не сотрудника?
Или я неправильно понял и вы ищете исполнителя, а не сотрудника?
Мало того, отсутствие квалифицированного менеджмента и аналитиков, пытаются заменить одним программистом. Т.е. явно, что с подобными конторами, можно связываться только, если уж совсем деваться некуда. Изумительные наглость и хамство ...
Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса"
К этой цитате есть следующие замечания:
Грамотность (т.е. её отсутствие)
Неумение формулировать мысль.
Задачи бизнеса решает менеджмент, иногда используя программистов как ресурс. Неумение использовать ресурсы правильно, - стратегический (или тактический если подобное происходит редко) прокол менеджмента, а не программиста.
Никакую контору не спасёт супер-пупер-программист, если заказчик (в данном случае внутренний) сам не знает чего хочет, и когда догадывается, что чего-то хочет, то выразить это не в состоянии.
Все стороны правы, а все потому, что и Минтруд, и читатели почему-то возлагают на разработчика слишком много. До разработчика должны поработать бизнес-аналитик, системный аналитик, архитекторы, а уже потом разработчик может просто следовать ТЗ (почти). Но, о чем это я, так же не принято и вообще где найти всех этих людей, правда это уже другой вопрос.
А про заказчиков справедливо следующее шуточное (но в каждой шутке есть доля шутки) утверждение и его нужно принять: "Заказчик никогда не говорит чего он хочет, а хочет он всегда не то, что ему нужно".
Самое прикольное, когда не то что тотально парализовано все управляющее звено, а даже никто не представляет как оно вообще работает: ни документации, ни карт процессов, ничего, либо все это только для внутреннего пользования, а программист обломится, он же джедай. ТЗ тогда идут уровня "сделай что-то, не знаю что, не знаю как, но чтобы работало как я придумал, но как придумал не расскажу". Реальная проблема часто до конечного разработчика даже не доносится, теряясь в пути. Такое себе.
Иногда читаю похожие посты с описанием того, как должна правильно работать разработка и думаю, как же раньше работали программисты без всех этих 10 человек, которые должны отработать до них? Не отрицаю, здорово когда всё делается по умному, но этот подход повышает порог входа в разработку для компаний и создаёт иллюзию того, что без этого уже ничего не создать в современном мире.
Да никто не отрицает, что один сеньор может сам все делать, просто обычно на такого человека наваливают столько в итоге, что ему уже не до деталей, а они нередко бывают важны.
Из своей практики могу сказать, что внедрить "правильный" процесс - вполне по силам, и "разделение труда" дает результат в виде возрастающего качества готового продукта.
При этом, если проект не сверхсложный (тут у каждого своя субъективная оценка), то схема "и чтец, и жнец, и на дуде игрец", конечно, будет работать.
Процесс в сущности должен быть попилен на участников, если есть перегруз. Современные реалии обозначают, по сути, на какие роли может быть попилен процесс, которые дали бы оптимальную стоимость команде разработки с точки зрения заказчика/работодателя.
Правильный процесс состоит из этапов, которые выполняют участники в разных ролях. Совмещение ролей - норма. Остальное зависит от потребностей.
Иногда читаю похожие посты с описанием того, как должна правильно работать разработка и думаю, как же раньше работали программисты без всех этих 10 человек, которые должны отработать до них?
Общались просто чаще и никто даже подумать не мог о такой концентрации на фискальных моментах, которые в принципе ни на что не влияют.
Например, пишет тебе человек: "Привет, я <такой-то такой-то>. Мне посоветовал тебя один хороший знакомый. Давай к делу.
Если в кратце, мне нужен сайт для (и далее перечисляет, что ему нужно в общих чертах). Я <такой-то специалист, деятель> (и далее рассказывает немного о себе).
На сайте обязательно должно быть (и далее перечисление функциональностей) и (далее пожеланий).
Напиши мне, что об этом думаешь. С уважением, <ФИО> <должность>."
И далее, уже программист пишет, что может сделать, по этапно расписывает план работы и примерный график работы и оставляет свои контакты. Обычно всё доходило до "через две неделю первый рабочий прототип" и далее уже в процессе регулярных созвонов и переговоров определялись нюансы. И естественно, никто за рамки оговоренного далеко не уходил, программист всегда был королём положения и заранее оговаривал условия, при которых работа будет считаться выполненной.
Ни о каких "обязательствах обновления" никто даже не задумывался, потому что критические баги отлавливались ещё до сдачи проекта, а самые-самые редкие никто не выискивал вовсе - всё что касается базовой функциональности, безопасности данных, устойчивости к нагрузке отлавливалось в ходе разработки, размениваться на мелочи - нерационально. Уважающий себя программист не позволял себе завершить работу над программой, предварительно не протестировав её.
Что делают менеджеры? Спекулируют на том, где им места нет изначально. И одновременно ищут чашу грааля, где будет видна разница между единоличником и командой разработчиков, ложно стремясь привести её к де-факто линейной экстраполяции. Отсюда и растут у них фискальные предварительные запросы, спотыкаясь об которые они либо только и могут, что жаловаться государям, либо не могу выбрать из них более приоритетные, и снова спотыкаясь, либо жалуются на "адский дефецит кадров", либо не могут выбрать вообще никого из откликнувшихся.
Вы посмотрите на текст статьи. Это же юрист писал, не меньше. И даже у них уровень развитого самоучки - это "ведущий программист", с совершенно необоснованными фискальными 3 года опыта работы в организациях. Отличный пример того. что Минтруд давно пора перестраивать, как и весь Ростехнадзор.
Насколько я понимаю, дело в том, что главная ценность сейчас в разработке - time to market. Без этих людей можно, но без них при равном качестве получится в разы дольше, просто потому что разработчику придется или согласовывать каждый шаг с представителем заказчика, или отделять написание гостовского тз в отдельный этап и прибивать тз гвоздями. Ну или отсеивать заказчиков, которые сами не очень понимают, чего им надо.
Ну или отсеивать заказчиков, которые сами не очень понимают, чего им надо.
А зачем связываться с невменяемыми людьми? Не все клиенты одинаково полезны.
Не все. Но иногда бывает сценарий "Липецкий кондитерский комбинат - спокойный среди бурь", чисто по Пелевину. То есть заказчик хочет офигенно, но вот готов ли он дать исполнителю полную свободу становится известно только на первой демонстрации. И вот тут надо принять решение - вникаем, расспрашиваем, работаем, или заказчик начинает просить поиграть со шрифтами и с ним прощаются.
Не, можно конечно по учебнику управления разработкой поступить и прямо влупить заказчику "или фиксируем бюджет и сроки, или фиксируем результат, или если даже понимания результата у заказчика нет - платите повремянку, ты башляешь, я пою". Но скорее с таким заходом он пошлёт вас первым)
Вот у меня ответ на все вопросы тоже - да.
Только я давно работаю сам на себя, как и многие другие с таким ответом.
Т.к. люди отвечающие "да" на все эти вопросы, уже не просто программисты.
Это предприниматели-программисты, с должностями в которых присутствуют слова Архитектор, Консультант, Лид и соответствующей оплатой их труда.
И это всё вот к чему. Какую вы предлагаете месячную оплату? Просто ради интереса :)
Действительно, исходя из этого стандарта, мы видим, что программист создает программный код, опираясь на техническое задание (готовую спецификацию). Для этого ему достаточно владеть синтаксисом выбранного языка программирования, уметь оптимизировать программный код и проводить оценку работ по срокам.
Так и хочется воскликнуть:
— А судьи кто? — За древностию лет
К свободной жизни их вражда непримирима,
Сужденья черпают из забытых газет
Времен Очаковских и покоренья Крыма;
Автор
А. С. Грибоедов
Как здорово, что нас учили, руководствуясь словами, которые можно назвать мировым стандартом на программиста, выдающегося советского учёного, одного из пионеров теоретического и системного программирования академика Андрея Петровича Ершова (статья «О человеческом и эстетическом факторах в программировании», 1972):
Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста.
Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста.
Раньше когда писали машинный код, и память была суперограничена, то действительно программистами были только настоящие гении, оптимизирующие каждый такт процессора 0x5f3759df. Даже собеседования было проводить легко, ведь человек либо понимал о чем говорит, либо абсолютно не понимал.
Но сейчас то всё настолько высокоуровнево, что 90% программ - это просто разного рода CRUD'ы, разные интеграции между программами, перекладывание информации с одной проги в другую, и рисование интерфейсов, а памяти - хоть жопой жуй.
Остальные 10% сложных (скажем так - с высоким порогом входа) - это high-load проекты, и machine learning. Требования к сверх-гениальности в индустрии разработки давно уже снизились.
Эк вы все научное ПО проигнорировали. Наверное, уверены, что одной левой пяткой напишите софт для компьютерного моделирования лекарств или там спутниковой интерферометрии?
И эмбеддед по хорошему тоже.
Конечно, есть ещё довольно много сфер, где всё требования высокие. Я не ставил целью посчитать точные проценты (90% и 10% взяты из головы и не имеют обоснования), и не ставил целью своим комментарием провести научное исследование по ИТ-сферам и требуемым компетенциям, а хотел обозначить разницу между требованиям к программистам тогда (50 лет назад в 1972), и сейчас в 2022.
Ну так 50 лет назад не существовало ни радарных спутников высокого разрешения с общедоступными данными на всю планету, ни софта для их обработки в облаке, доступного непосредственно в веб-браузере любому желающему. Как вообще можно сравнивать? Если вы серьезно считаете, что какой-нибудь солвер на фортране написать сложнее, то вынужден вас разочаровать…
Ещё раз. Я не говорю, что работа со спутниками сейчас стала простой, и что не осталось сложных задач. Я говорю о том, что 50 лет назад, чтобы написать любую программу - начиная с игры на денди, заканчивая какой нибудь микробухгалтерии ты должен был быть уже неплохим таким специалистом с очень крутыми скиллами. Сейчас эти же самые задачи выполнит даже начинающий разработчик, ничего гениального для этого не нужно. Из этого следует, что требование:
должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц
Именно это требование более не актуально.
А тут сложность именно разработки или знания предметной области?
В случае с научным ПО - в первую очередь разработки: знания аспектов инфраструктуры используемого языка в первую очередь - библиотеки, оптимальные алгоритмы/контейнеры и прочее в том же духе. Особенно плохо если ко всему этому ещё нет и какой-то минимальной верификации написанного. Ну и велосипеды с костылями, куда же без них. Если у нас есть некоторый железный аппарат, то сложность разработки ещё подрастает, причем независимо для аппарата софт, или для обработки данных с оного аппарата. Сама предметная область которую можно закодировать относительно простая - сюда map, туда reduce, туда фурье, сюда интеграл, смыть, намылить, повторить.
Особнячком тут всякие SAT-солверы и прочие логические proof assistant, тут уже предметная область обычно сложнее.
Работал в некотором НИИ (CV на эмбеде), так у нас был тандем разработчиков. Один - чистый математик, орудовал Матлабом и подобными пакетами. Второй - программист, писал непосредственно код, втискивая математику первого чувака в ресурсы DSP и ПЛИС. Так что многофакторность сложности задач была сбалансирована подбором специалистов.
Работал с приложениями, написанными специалистами исключительно в предметной области. Первое такое приложение было на ЕC1040, в 1993, нас, студентов, гоняли в Бауманке считать прогиб балки по сопромату. Рассказал бы про впечатления, да мат на Хабре запрещен.
Про софт софт для компьютерного моделирования лекарств ничего не скажу, но когда мне коллега популярно объяснил, что такое спутниковая интерферометрия, понял, что ничего там нет сложного... )
Мне Паваротти не понравился, картавит, в ноты не попадает...
- Вы были на концерте Паваротти?
- Нет, мне Рабинович по телефону напел
Не осилил аллегории
Вы говорили, что вам друг на словах всё рассказал, и вы посчитали, что там всё просто (ничего сложного). А вдруг, друг вам всё упростил, рассказал по-своему, и только небольшую часть, а дьявол кроется в деталях, и там все не так просто.
А так как вы не попробовали, то вы не узнали наверняка, доверившись информации со слов друга.
Не друг, а коллега, кандидат наук, закончил МИИГАиК по направлению спутниковая интерферометрия. Не просто рассказал, а много раз обсуждали различные реализации, многие затем тестировали.
Ок , но согласитесь, что:
кандидат наук, закончил МИИГАиК по направлению спутниковая интерферометрия. Не просто рассказал, а много раз обсуждали
И
когда мне коллега популярно объяснил, что такое спутниковая интерферометрия
Далеко не тоже самое. Во втором, слова "когда объяснил" имеет смысл, что он сделал это разово, буквально за кружкой пива.
Я с вами тут немного не согласен, низкоуровневую разработку никто не отменял (ещё процентов 10-15 можно накинуть). В большинстве железячных проектов очень часто приходится разбираться в особенностях микроконтроллера или процессора, работать с таймингами, памятью, прерываниями, кастомными протоколами передачи данных, проводить реверс инжиниринг вообще в порядке вещей из-за частого отсутствия нормальной документации и т.д. Особенно в текущий момент времени, когда все заказчики просят сделать подешевле, а из-за дефицита железа это чаще всего переход к менее мощному железу или очень непопулярному железу, где многие вещи нужно реализовывать самому.
Лет 5 назад пришлось стряхнуть пыль с тех извилин, которые в начале 90-х занимались программированием - ввязался в стартап, где на какой-то STM'ке делали интерактивный пульт, работающий по I2C... там, конечно, не голый asm в среде без окружения, но RTOS в полный рост... долго ловил нужные тайминги, чтобы I2C нормально поднялась... но потом пришёл разработчик интерфейсной части и попортил всю малину - работал либо тачскрин, либо I2C... так и отвалился я от того проекта, не став embedded-программистом.
Эти два слова неотделимы.
Именно так. И эти два слова коррелируются с высказыванием академика Ершова А.П:
Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста.
Вот бы тогда зажили — можно было бы кодить по ТЗ, не подтягивая всех программистов до уровня «ведущего». А то ещё, гляди, все захотят и зарплату «ведущую» — то-то заказчик обрадуется в разы увеличившемуся счёту.
Проблема в том что хорошего бизнес-аналитика найти ещё сложнее чем хорошего программиста. А если даже и найдёшь, то зарплату они хотят тоже не меньше чем программисты. Мягко говоря.
Поэтому как минимум у нас "бизнес-аналитик" это часто просто один из вариантов развития карьеры программисты после сениора. Наряду с тимлидом и архитектом.
Ну и точно так же как и в случае с тимлидами/архитрктами многие просто совмещают это с программированием в тех или иных пропроциях.
Бизнес-аналитики часто пишут такую хрень, что ее невозможно реализовать и иногда между ними и программистами еще есть systems analyst/functional analysts, которые как раз с техническим бэкграундом приводят сказочные хотелки к реалиям.
Не знаю, где это там «у вас», в моей практике обычно такие люди вырастали из QA. Которые в силу своей деятельности обычно умеют пользоваться написанным софтом по назначению, а также знают, как оно должно быть, потому что читали требования. А вот как раз программистов, выросших в бизнес аналитика, не встречал за примерно 30 лет никогда.
В том числе и из-за денег. Кроме того "лепить 100500-й crud" в какой-то момент тоже становится скучно. А тимлидами иои архитектами тоже не все могут или хотят становиться...
Да никто никому ничего не внушает и никто никого ни к чему не принуждает.
Ну во первых а у чём принципиальная разница? А во вторых большинство при этом продолжает часть времени кодить.
Я например считаю, что программист — это создатель систем. Значит его развитие должно идти по направлению увеличения производительности/влияния на создание систем.
Джун — делает что скажут, но вносит свои кирпичики
Мидл — хорошо делает порученный кусок принимая тактические задачи
Синьер — менторит джунов принимает частично-архитектурные решения
Дальше вилка:
Архитектор (кодовый) — принимает решения, как технически будет устроена система
Тимлид — может больше чем один программист, так как ведет команду
РП — отрыв от собственно кода, руководство созданием системы в полном объеме (но по чертежу от аналитиков)
Бизнес аналитик — принятие решений, а какой собственно будет система.
Поэтому как минимум у нас "бизнес-аналитик" это часто просто один из вариантов развития карьеры программисты после сениора. Наряду с тимлидом и архитектом.
Ну и точно так же как и в случае с тимлидами/архитрктами многие просто совмещают это с программированием в тех или иных пропроциях.
Назовем это низкоуровневым и высокоуровневым программированием. Но не с точки зрения машинного кода, а с точки зрения близости к удовлетворению бизнес потребностей.
Очень разные эти миры. Мир бизнес фреймворков (CRM, ERP etc) и мир технических фреймворков (Swing, Hibernate, Laravel etc). Одни соприкасаются тесно с реальными бизнес процессами, другие живут только в технических процессах.
И когда "у нас" это ERP или подобное, а у читающих это Swing или похожее, то у них взрывается мозг. Совсем разные роли и команды.
Такое ощущение, что логика автора 1 проект - 1 программист. Больше в команде никого нет, и не предвидится.
Скорее всего автор описывает свою текущую боль)
В разных компаниях все по разному - в более мелких, программистам не редко приходится выполнять кучу разных ролей: аналитик, программист, тестировщик, девопсер, тех.писатель. Не редко в мелких компаниях и стартапах как такового ТЗ и вовсе нет. В более крупных компаниях разделение труда встречается гораздо чаще, в таких компаниях программисты чаще всего занимаются разработкой приложений строго по ТЗ, и отступление от него не то что не приветствуется, а очень даже наказывается.
В известных мне крупных продуктовых IT-компаниях как раз программисты, которые могут подумать головой - дозаполнить какие-то пропуски в постановке задачи или указать на её неполноценность/некорректность, предоставить какой-то пушбэк - ценятся куда больше, чем "программисты по ТЗ".
Если речь о каком-нибудь там галерном аутсорсе, то да, там другой мир, но там совсем неинтересный мир для рядового разраба, как по мне.
Особенно вы правы для случаев, когда тз ставится аналитиком, который сам мягко говоря пофигист.
Чем больше компания, тем больше в ней бюрократии и тем меньше участие конечного программиста в ТЗ.
Пойду расскажу знакомым гуглерам и прочим сотрудникам фэйсбука, чо.
Да и сам как бы в компаниях с тысячами сотрудников работал и работаю - нет ничего подобного. Да и ТЗ, строго говоря, очень часто нет.
В крупных компаниях любят KPI и там наверняка не учитываются доработки ТЗ.
А попытки объяснить, что не так в ТЗ - это весьма немалые временные затраты.
В больших компаниях такие разработчики очень быстро становятся теми, кто эти ТЗ вобщем-то пишет для тех, кто занимается разработкой строго по ТЗ, т.к. они им не хватает предприимчивости для анализа бизнес процессов и идей для улучшения.
В крупных компаниях рост обычно строится по следующим принципам:
"Может написать код по ТЗ"
"Может понять, что нужно заказчику и написать код" (senior)
"Может аргументированно показать заказчику, что он все придумал неправильно и рассказать, как надо сделать по-хорошему" (principal)
Так что "чистые кодеры" обычно так и остаются на первом уровне без всяких promotions.
Может аргументированно показать заказчику, что он все придумал неправильно и рассказать, как надо сделать по-хорошему
Я не знаю, это вы пошутили или нет, но так действительно частенько бывает с клиентами :)
Какие шутки - это почти дословный пересказ нашего leveling guide.
Я когда нанимаю профессионалов (типа строителей или бухгалтера) я тоже ожидаю, что они если нужно скажут - "чувак, ты придумал дичь, это плохо поэтому и поэтому, давай сделаем вот так и это будет хорошо". Собственно для того и нужны профессионалы. Если компания делает автомобили, то глупо ожидать, что они будут так же хорошо разбираться в ИТ.
Треугольник Хопкинса "быстро, качественно, дешево" лишь один и вариантов тройственной ограниченности. В случае с ТЗ, будет свои варианты - точные сроки, точный бюджет.
Если клиент готов вести разработку по варианту "пилим пока мне не понравится", не вопрос, вопросы будут только если он при этом потребует что бы ему сказали точную сумму, и точные сроки, и не хрена не захочет понимать когда ему начнут задвигать что отрицательный результат в таком варианте работы - тоже результат, который надо оплачивать.
Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса.
Типичная стратегия внешнего подрядчика по-умолчанию.
Нормальная стратегия. Если ты сам переписал ТЗ и сделал как считаешь нужным - оставь это себе и заплати сам.
Клевая стратегия. Прямо недавно её в хирургии видел.
Ситуация: пациента уложили на стол, усыпили, а потом хирург "ни шмагла"
Тете объясняли, что абсолютно честно не берут с неё денег за операцию. Но берут за анестезию. Так как консультация с анестезиологом была, лекарства на усыпление потрачены, и даже живой её разбудили.
А тетя пыталась объяснить, что без операции ей эта анестезия даром не нужна. А тем более за те деньги, что с неё содрать пытаются.
Вот прям каноничный случай поэтапной оплаты по ТЗ.
Хотя… типичные внешние пусть так и делают. Те, кто берут денег за решение проблем, а не выполнение работ будут в плюсе. Сарафан благо работает.
Ваш пример про хирургию - он за мой комментарий. У тетки было тз, медики его переписали по своему - остаются без денег.
Если вам дали ТЗ - то вы не решаете проблему, вы производите работы по ТЗ. Комментировать ТЗ можно конечно. Моя практика показывает, что обычно ты теряешь время на объяснения граничных случаев, если речь о реализации, и натыкаешься на "не учите меня делать бизнес" в чем-то более глобальном. Ну а если ты "такой важный куриц", пришел с ТЗ - зачем я буду тебя учить?
Пришел бы с проблемой - решали бы проблему.
Если вы строитель отделочник - вы просто клеите обои, а между тем - в основе всей движухи был тезис (проблема) "нам нужна просторная квартира для нас, детей и собаки". Вы ведь не будете покупать собаку или квартиру заказчику?
Автор полностью прав. В начале карьеры как раз был таким программистом который требовал от заказчика всё учесть в ТЗ, хотя заказчики в большинстве своём сами не представляли что им нужно. Ладно хоть со временем я осознал что именно своей компетенцией могу предложить то, что действительно нужно. И с тех пор стал особенно ценен для заказчиков. Так что если кто не верит автору - подтверждаю истинность вышеописанного собственным опытом.
Если заказчик не знает, чего хочет, то разве это проблема программиста? Пусть узнает и приходит. Аналитики, консультанты, менеджеры, проектировщики - есть, к кому обратиться. Не надо всю ответственность перекладывать на программиста, называя его к тому же низкоквалифицированным. Без внятного техзадания есть шанс всё постоянно переделывать из-за меняющегося настроения.
PS. А если программист all-in-one, то и цена за его услуги должна быть соответствующей.
Вот и я раньше так рассуждал. ИМХО лучше вовремя внести свою лепту, чем работать над проектом, зная что он станет мертворожденным. Профессионал на то и профессионал, что разбирается в том что делает, и знает как нужно делать а как нет. Другой вопрос, что проектирование архитектуры проекта - отдельная работа, которая требует доплаты, с этим никто и не спорит.
заказчик не знает, чего хочет
Заказчик почти всегда хочет увеличения прибыли. Поэтому он приходит к разработчику с запросом "хочу автоматизировать вот это вот" или "сделайте мне аналог вот этой штуки".
Зачастую заказчик имеет какое-то представление о том, как это должно выглядеть в целом, но не имеет совершенно никакого представления о том, как это будет выглядеть в деталях.
В этом случае задача аналитика или "тыжпрограммиста" - путем изучения предметной области и допроса заказчика по шагам узнать:
Не хочет ли заказчик странного (действительно ли запрошенный продукт решит озвученную проблему бизнеса).
Понимает ли заказчик объемы предстоящих работ ("вот вам миллион, сделайте мне вконтакте" - редко, но случается).
Вместе с заказчиком и конечными пользователями (где применимо) описать все частные случаи глобальной проблемы и заодно выяснить, решаемы ли они.
Составить детальное ТЗ, которое будет прозрачно и понятно как заказчику, так и исполнителю.
Наличие ТЗ обычно подразумевает, что предыдущие три шага уже пройдены (либо с вами либо с какой-то "предыдущей конторой"). Если это не так и вы беретесь за разработку на основе такого ТЗ - у вас с очень большой вероятностью будут проблемы по итогу (либо заказчик "не работает как надо - платить не буду", либо разработчик "на эту фичу еще два месяца работы, а в ТЗ ее нет - бесплатно делать не буду").
P.S.: В общем если возникает проблема "в ТЗ этого нет" - то это недосмотр того, кто ТЗ составлял.
Если ТЗ делали вы, то и ответственность на вас. Если это делал кто-то до вас, то вы просто должны донести до заказчика, что ТЗ не ваше и за отсутствие в нем фатальных недостатков без тщательного аудита вы не ручаетесь.
Если ТЗ делали вы, то и ответственность на вас.
Нет, ответственность за ТЗ на том, кто его согласовывал и подписывал. То есть на заказчике. ТЗ вообще для чего нужно? Чтобы формализовать задачу. Чтобы убедится, что программист правильно понял заказчика. ТЗ - это по сути, договор. Перед подписанием ТЗ заказчик его читает и всегда может сказать, что "надо добавить это это это" или "это это это убрать/переформулировать". А если заказчик подписал ТЗ, значит он согласен со сроками, объёмом работ и стоимостью и все то, что не вошло в ТЗ за доп. плату.
Я не спорю с тем, что договор есть договор и исполнитель имеет право заниматься буквоедством в случае с ТЗ.
Я о том, что я считаю морально безответственным поступком браться за работу над проектом не убедившись в том, что ТЗ соответствует ожиданиям заказчика и что заказчик действительно понимает, что именно у него написано в ТЗ, поскольку ТЗ зачастую составляет либо (вероятно) некомпетентный в составлении ТЗ заказчик, либо компетентные, но (иногда) незаинтересованные в результате третьи лица.
Я не говорю, что вы обязаны проводить полный аудит ТЗ бесплатно, однако если вы прочитали ТЗ, заметили какие-то логические нестыковки и не попытались выяснить в чем же дело, то вы гарантированно поимеете проблем на сдаче.
Мне кажется, тут проблема рассуждений в плане "ответственности". Это все не про ответственность, а про повышение собственного скилла. От прогера не должны требовать сбора информации от заказчика, однако он должен стремиться разобраться самостоятельно. Это просто повысит тебя как специалиста.
Если заказчик не знает, чего хочет, то разве это проблема программиста? Пусть узнает и приходит.
А чего хочет программист? По-моему, сидеть, понимать, что тебе дали задачу "делать какое-то говно" и ожидают, что ты будешь молча сидеть и делать говно - это ад наяву просто. Я проверял, я не могу работать в аутсорсе, выгорание наступает уже позавчера.
PS. А если программист all-in-one, то и цена за его услуги должна быть соответствующей.
Естественно, потолок заработка это тоже увеличивает. Как и список компаний, где вам (/мне/другу сына маминой подруги) будут рады как специалисту.
Мы говорим не про обезьяну-кодера или про профессионального программиста-ИТ-консультанта? В этом между ними и разница.
Будьте осторожны, за такие мысли выше минусуют)
Заказчик как раз обычно знает, чего он хочет. Как бы это странно ни звучало. Просто свои пожелания он выражает на своем языке. Условно говоря, один говорит на хинди, другой на суахили, а для общения между собой они используют google переводчик.
Сейчас же я хотел сказать о другом, что путь "пусть узнает и приходит" - тупиковый изначально. Потому что грамотный заказчик найдет толкового тематика - именно так раньше назывались люди, которые писали ТЗ для конкретной задачи. Потом это стало называться, вроде бы, проект-менеджером. Как сейчас, не знаю. Архитектор - это тот, кто проектирует решение по готовому заданию. Так вот, тематик напишет ТЗ, в котором будет предусмотрено все, что только возможно, все варианты интерфейса, все алгоритмы обработки данных - садись и кодируй. Только (surprise!) 80-90% бюджета уйдет тематику, а кодеру - 10-20%.
Поэтому вариантов нет: если речь идет об IT-компании или хотя бы команде, то нужен минимум один "полиглот", если речь об одиночке - ему придется самому стать "полиглотом".
Имхо, фигня в профстандарте написана. Junior? Middle? Senior? Нет, только "инженеры-программисты", только хардкор.
Люди, писавшие профстандарт, ни пса не понимают в программировании. Постановщик требований - целая специальность. Бизнес-аналитик, системный аналитик, проектировщик интерфейсов, системный архитектор, специалист по программно-аппаратным платформам, проектировщик алгоритмов, кодер, тестировщик - это всё разные люди. Разделение труда, всё по Адаму Смиту. И только динозавры в профстандарте ждут, что придёт "тыжпрограммист" и во всём разберётся и сделает всем хорошо, и угадает то, чего заказчик, профессионал в предметной области, не угадал. Ага, щаз пойду интервьюировать, а потом сяду код писать, и тесты ещё, и блок-схемы алгоритмов по ГОСТу для некрофилов нарисую.
Заминусуют - ну и плевать.
Судя по сему, автор: программист-оркестр, полный фуллстек в одном лице, от переговоров с заказчиком и до бета-теста все делает сам, берется за небольшие заказы и мучается с ними - годами
Junior? Middle? Senior?
Junior = техник минус программист;
Middle = инженер минус программист;
Senior = ведущий инженер минус программист.
У техника/инженера еще категории есть. Что не так то?
Не так то, что у Seniora обязанностей по профстандарту и анализ требований, и бизнес-анализ, и системный анализ, и эргономика интерфейса, и архитектура.
И? Собственно:
Что мешает то же самое делать ведущему инженеру? Или что то поменяется от того что ведущего назовут синьором?
При чем тут профстандарт вообще? Обычно от работника требуют выполнение "должностных инструкций", а там уже работодатели пишут все то что необходимо от ведущего./инженера/техника.
блок-схемы алгоритмов по ГОСТу для некрофилов нарисую
Я видел такго перца на собесе, который в ответ на просьбу сделать дома тестовое и прислать его, на самом деле распечатал код тестового на листе бумаги формата А4 с этой рамкой по ГОСТ и потом припёрся в офис с этим листом что бы передеть его тимлиду через секретаршу. А меня так учили (С).
То что джун-мидл-сеньер называются "младший программист" (освещен в статье) — программист (не освещен) — ведущий программист (освещен) вас как-то особенно больно ранит?
Да, вся указанная вами толпа народа — это разные роли и могут быть разные люди. Их еще и разное количество (пропорционально) на проекте нужно.
В назвали 9 ролей, с учетом разной представленности в сбалансированной команде будет минимум в раза больше народу (на одного архитектора нужна пара бизнес аналитиков, пяток кодеров, тройка тестировщиков и тд).
По вашему командой меньше чем из 30 человек для создания бизнес софта лучше не собираться?
По-моему, можно совмещать. Проблема не во мне. Проблема в том, что по профстандарту ничего более-менее сложного разработать нельзя. У нас что, профстандарт для фри-лансеров пишется? Вообще-то по нему ггоскорпорации работают. Поэтому они ничего и произвести не могут. Организационные провалы не могут быть компенсированы качеством исполнителей.
Все абсолютно верно пишешь, разве что забыл указать, что саппорт продукта ещё отдельный и желательно не связанный ни с заказчиком, ни с исполнителем) Только вот и ответственность получается размытой между всеми звеньями и в итоге "косяки" циркулируют по кругу между всеми звеньями, перебираясь из старой ветки в новую в бесконечном цикле))
Я не критикую, я как тот китаец за течением реки наблюдаю)
Ещё, мне показалось, что автор писал больше про контекст ответственности, чем про техпроцесс, как таковой.
Насколько я знаю профстандарт, никаких должностей типа "бизнес-аналитик", "системный архитектор", не говоря уже про "архитектора базы данных" там нет. Всё это должен уметь делать "ведущий инженер-программист". Обязанностей у него выше крыши, как и требований "должен знать", "должен уметь". Каждый суслик - агроном. За этим проглядывает желание переложить всю работу на исполнителей.
значит, у нас должен быть точно такой же стандарт на врачей. Не врач-уролог, врач-терапевт, врач-хирург и прочие, а просто "мед сестра", "старшая мед сестра", "младший врач", "regular врач", "старший врач", "ведущий врач", "главный врач". И никаких специализаций
Года с 2004 или 5го не интересовался и не следил за изменениями, но насколько помню, в той области приоритетнее были документы в рамках орг-ции с названиями "должностная инструкция/обязанности, штатное расписание" и тп, в которых прописывались любые нюансы, например - запрет подходить к серверу ближе 1 метра тк на должность инженер-программист оформлялись, чуть ли не уборщицы, а в рамках ИТ отдела набор должностей регламентирован. Я это к тому, что формализм и реальность даже в тех рамках стыковались, хоть и смешным образом.
То есть формализованная система управления разработкой нежизнеспособна. Приходится брать людей на эти должности, но занимаются они совсем не тем, что прописано в профстандарте. Насколько я знаю, должностные инструкции проверяются на соответствие профстандарту. Больше может быть написано, меньше - нет. В итоге написано столько, что лучшие спецы, прочитав даже базовую должностную инструкцию, впадают в кризис собственной неполноценности.
Автор совсем не в курсе такой специальности как "менеджмент"?
Менеджер не должен разбираться в программировании, а программист принимает кучу низовых решений, которые сказываются на продукте - какой минимальный API телефона поддерживать, какой API выбрать для работы с камерой, что делать при возникновении Exception, как поддерживать или не поддерживать ночную тему аппарата...
Минимальный апи неразрывно связан с версией ОС, что в свою очередь связано с охватил аудитории. Такие вещи - чуть ли не самая важная часть любого нормального ТЗ
Про исключения вообще можно целый раздел писать - реакция приложения на ошибки
Ну и все остальное, если не вдаваться именно в техническую реализацию (код) тоже вполне себе понятно любому менеджеру и больше того, он обязан знать такие нюансы просто даже хотя бы из опыта реализации проектов. Это если мы конечно про менеджера проекта говорим
Хороший менеджер - ессно должен разбираться в программировании, лучше менеджеры получаются из программистов
В составлении ТЗ, точно также ессно - должен участвовать и тот, кто в разбирается в программировании. Но не кодер, а кто-то уровня тимлида, который, по сути - тоже есть менеджер
Да вот знаете, ничего один другому не должен. Может заказчик заплатит хотя бы раз в 100 больше что бы за него на родном языке изложили что же все таки он хочет в итоге, а может за него еще и подумать надо? Можно конечно win-win о чем все говорят, но кажется, что то не так :D
Извините, а бизнес-аналитики, менеджеры там всякие, они для чего нужны? Если всем этим должен заниматься программист.
Статья скорее показывает взаимоотношения между заказчиком и программистом на фриланс бирже, в нормальных компаниях уже давно есть аналитики и менеджеры которые и выясняют все требования и все уточняют.
Я искренне не верю, что при разработке сложного продукта, а не очередного банкокруда по шаблону, аналитики и менеджеры в состоянии покрыть вопрос так, чтобы программист мог не глядя брать и делать. Очень много технических мелочей бывает, в которые они не погружены, и программисту надо вникать в детали, уточнять их, в какой-то момент ещё и зачастую предлагать возможные трейд-оффы ("вот эту фичу мы или будем делать 3 месяца вместо 1, или мы сделаем только 50% из заявленных возможнстей, но за 3 недели, или же мы сделаем фичу за полтора, но это затронет аспекты X и Y продукта").
Так и есть. Но минимально проработанное ТЗ при этом быть обязано, чтобы как минимум до исполнителя донести суть проблемы и желаемое решение, причем понятным для исполнителя языком, с учетом того что исполнители могут быть далеки от бизнеса и его потребностей. Это если команды совсем маленькие, и в роли архитектора сам исполнитель выступает. Но нужно понимать последствия: таких архитекторов в итоге на проекте 70%, все разного уровня, зачастую без понимания предметной области и проблем бизнеса, что там они напроектируют страшно представить, для этого и нужно централизованное управление, один ответственный за архитектуру или аналитику. Разгребать последствия через пару-тройку лет заказчику за свой счет предстоит, так что это не экономия на архитекторе и аналитиках, это попытка отсрочить расплату за ошибки.
К сожалению все зависит от уровня программиста, один пишет, что при повороте телефона сразу креш, а второй пишет, что и ночная тема и для слабовидящих все сразу работает. На трудозатраты обычно это мало влияет, просто профессионал знает как делать сразу быстро и правильно.
А имеете ли вы моральное право задавать такие вопросы?
Да, после того как ТЗ и сумма оплаты утверждены — имею полное моральное право. Просто так я никому ничего не должен. Какие-то древние ГОСТы по разработке ПО никакого отношения к бизнесу не имеют и ни к чему меня не обязывают
Кстати, да. Суть статьи свелась к тому, что "Не участвуешь в составлении ТЗ -> не имеешь права называться ведущим программистом по ГОСТ"
Я недавно пробовал сделать устройство лучше ТЗ, (в написании ТЗ участвовал, но тогда еще было непонятно, что вообще получится) - мне сказали, чтобы не тратил время.
С другой стороны, понимаю, что бесконечные улучшения занимают бесконечное время, но принесут конечную пользу. Поэтому я пока в раздумьях.
Статье помогли бы несколько жизненных примеров.
для проверки бизнес-гипотезы - не нужны никакие улучшения, так что не разумывай, делай то - что прописано в ТЗ. Все улучшения предлагай, но не делай без одобрения
Я недавно пробовал сделать устройство лучше ТЗ, (в написании ТЗ участвовал, но тогда еще было непонятно, что вообще получится) - мне сказали, чтобы не тратил время.
С другой стороны, понимаю, что бесконечные улучшения занимают бесконечное время, но принесут конечную пользу. Поэтому я пока в раздумьях.
Тут как в старой китайской мудрости: "Когда бушует ветер перемен, одни строят укрытие, а другие ветряные мельницы".
Если есть порыв вдохновения, то просто берёшь и делаешь. И не надо тут с ними советоваться - когда работа уже сделана на 80% и даже если приближаются крайние сроки, то только у умалишенного возникнет искушение пойти против твоего творческого потока.
И даже мучить себя раздумиями не стоит. Просто берёшь и делаешь, а там договорится всегда можно. Ставят крайние сроки преждевременно только совсем больные на голову люди.
А вот меня в институте учили (еще в 90-ые!!!), что ТЗ пишет исполнитель на основе тех. требований от заказчика. Т.е. этапы такие:
Тех. требования. Пишет заказчик. Отвечают на вопрос "чего надо?"
ТЗ. Пишет исполнитель. Отвечают на вопрос "Как поняли и что будем делать?". Утверждаются заказчиком
Тех. проект. Пишет исполнитель по факту выполнения работ. Отвечают на вопрос "Что в итоге сделали?"
По градациям программистов я согласен. А то сейчас, куда не плюнь, - все ведущие-сеньоры. Но мало кто понимает, какую задачу бизнеса решают их творения. Т.е. код-то качественный, но делает не то, что хотел заказчик...
Вероятнее всего, Вас учили под влиянием советских ГОСТов. А советские ГОСТы написаны для организаций, минимум - для сторон договора, Поэтому брать на работе кодера и тыкать ему в лицо ЕСПД с порядком разработки ПО - глупость. Возьмите этот ЕСПД и ткните в директора, пусть выделяет людей для составления ТЗ и этого всего.
Более того, если не ошибаюсь, составление ТЗ - отдельный этап разработки, и оплачивается отдельно. Апосле утверждения заказчиком ТЗ он находится в большой зависимости от разработчика, т.к. ТЗ писал разработчик, а заказчик наверняка захочет это ТЗ поменять.
Опять же, ГОСТ сильно устарел, а методология разработки сильно продвинулась.
Ну меня учили не в России и уж точно не под влиянием советских ГОСТов. Но почему-то учили примерно тому же самому. Да и если посмотреть на реальность, то это самое ТЗ, по которому потом работают программисты и по которому потом принимают результат, обычно заказчик в одиночку не составляет.
То есть это либо заказчик совместно с исполнителем. Либо его делает исполнитель и отправляет заказчику на подтверждение.
Видите ли в чем дело... В Вашем комментарии фигурирует заказчик, исполнитель и программистЫ. Автор же утверждает, что "настоящий программист" сам ТЗ составляет. Ещё этот "настоящий" проводит бизнес-анализ, системный анализ, строит архитектуру, кодит, тестирует, сдаёт. Такой весёлый у нас профстандарт. В целом я не против, но всё зависит от размера проекта. На маленький проект, если хотите сэкономить, проект ТЗ лучше подготовить для программиста. На большом нанимать одного кодера или только кодеров, да ещё и заставлять их писать ТЗ - идиотизм.
Понимаете, если у вас на проекте несколько кодеров, но при этом один из них участвует в составлении ТЗ, а остальные нет, то скорее всего этот один будет получать из-за этого большую зарплату. И я не знаю как у вас, а у нас в этом деле всегда участвует кто-то с "техническим бэкграундом". Обычно кто-то из кодеров.
Все так. И зачастую даже несмотря на наличие батальона менеджеров и аналитиков оказывается, что проект понимают тимлид и пара сеньоров. Они же и способны за одну встречу разрулить новые требования заказчика. А остальные для мебели.
Более того, взгляды некоторых крупнейших компаний напрямую предполагают, что разраб должен быть строго изолирован от кухни сбора требований и составления тз. Для этого они нанимают 22-летних девочек "аналитиков". На деле оказывается, что название их должности происходит вовсе не от слова ἀνάλυσις, а от другого похожего. Постоянная война с этими буратинами может так утомить разраба, что он реально придет в состояние "нет в тз - нет в коде" - даже есть с его квалификацией все в порядке.
Мы привыкли слышать жалобы на дефицит кодеров. Так вот дефицит хороших аналитиков (который от слова ἀνάλυσις) раз в 10 жестче.
поддержу, но есть еще целая каста аналитиков, которые адекватные и хорошие и помогают разработчикам, чтобы они не отвлекались на бессмысленную возьму и коммуникацию с заказчиком внутри энтерпрайза, потому что у этих ребят зачастую 7 пятниц на неделе. И это очень утомительно объяснять, что вот это мы делать не будем, это невозможно, а можно сделать только это и только за много денег. И для этого необязательно, чтобы "аналитик был хороший" или "отличный". Но хотя бы был с мозгами. Тут уж скорее архитекторы самые бесполезные люди - которые и умеют только рисовать схемки по тогафу, а в реальности система работает совсем по-другому. На самом деле я видел и нормальных Архитекторов, но кажется, что их еще меньше, чем толковых аналитиков.
Тем не менее, если вы хотя бы чуть-чуть поменяете свое мнение в сторону большей клиентоориентированности, то сможете понять, о чем я.
уважаемые коллеги пограмисты, услыште меня:
Не надо перегибать палку в клиентоориентированности, от этого страдает и качество ваших продуктов. в банковских приложениях появились "сториз" из инсты, зато более важные кнопки "оплатить" "перевести" "пополнить" отошли на второй план. в мессенджерах половину функционала занимают смайлики, стикеры, гифки, звонки.. а в нормальное форматирование текста кроме телеги и матрикса никто не умеет. повсеместный переход на CSD и электрон, запихивание в web того чему лучше быть нативным, в половине софта отсутствует как класс интеграция с другим подобным софтом (даже импорт и экспорт уже мало кто делает).
если клиент предлагает сделать ху**ю не стесняйтесь ему это сказать и главное объяснить. опыт подсказывает что если клиент вменяемый то с ним можно вести диалог, а если невменяемый то учше с ним не иметь дел ни за какие деньги.
возможно за этот крик души меня заминусуют, так что просьба к тем кто уже потянулся жмакать "минус" не полениться и написать чому собсна минус.
Взгляните на это иначе: если сториз в банк-клиенте не нравятся вам, то совершенно не факт что они так же не зашли 80% не технической аудитории банка. Заказчик все же ближе к пользователю чем вы
За всякие соцплюшки и новые тренды отвечает не разработка, а маркетинг и менеджмент, те кто заказывают вечеринку, а не те кто ее организует. Как собственно и за развитие продукта в целом. У разработки тут инициативы почти нет, у них есть только ТЗ на эти все плюшки. Такова потребность бизнеса, именно за удовлетворение этой потребности разработке платят.
Опять абстрактно-пафосное "программист должен решать задачи бизнеса, а не писать код"?
Те критерии, которые вы описали больше напоминают "мистера Вульфа" из "Криминального чтива". Если вы хотите чтобы программист в одно лицо решал все проблемы вашего бизнеса, то прежде всего ответьте себе на вопрос - а готовы ли вы ему заплатить гонорар уровня топового кризис-менеджера?
Идея, конечно же, верная. Но не понятно при чем тут минтруд и почему его мнение должно както качественно влиять на мою работу.
А все что вы описали можно свести к клиентоориентированности + навыкам коммуникации. Если хотеть сделать работу так, чтобы клиент не чувствовал себя обманутым, то не нужны будут никакие формалистики от министерств
Много букв про то, что должен делать программист, и ни слова про то, что должен делать заказчик.
Автор, за статью Вам, конечно, спасибо. Допускаю, что именно в вашей предметной области, действительно нужно оценить критическим взглятом ТЗ, и возможно, подвергнуть сомнению те вещи в нём, которые показались странноватыми или неправильными. Но есть и другие миры - один из низ мир регламентного учета. Это вот то, где вы слышите такие термины как "НДС", "Налог на прибыль", "Распределение косвенных расходов", "Как двадцатку закрыть на сорок третий" и т.д. Может быть слышали про такое? Да, все это считается в каком-то софте и кто-то это тоже пишет :) И вот в этом мире - следование БУКВЕ (капс и болд здесь не случаен) ТЗ - ваша страховка в протоколе допросов по повестке. Потому что если в результате вашего "творческого осмысления" ТЗ, в котором было четко указано, что можно брать в качестве вычета по НДС, а что нет - получилось нечто иное, то разговор лично с Вами, поверьте - будет очень короткий. Если вы накодите по ТЗ, и в нем будет ошибка, в результате чего какой-то ваш клиент, или ваше предприятие, не доплатит того же НДС, либо налога на прибыль - как вы думаете, когда эту нитку раскрутят, к кому будут вопросы? К тому кто писал к ТЗ или к тому, кто его реализовал? Да-да, я в курсе, что когда практически в любом таком софте, при начале использования, вы соглашаетесь на то, что он поставляется как есть, и производитель не отвечает за любые издержки, вызванные некорретной работой оного. Такое есть. Но есть и обратное - законные требования контролирующих органов пояснить правильность расчета того или иного регламентного показателя. И если так окажется, что вы, накодя это, отошли от ТЗ, и результат вашей работы - требование от ФНС, или какого-то другого органа, то даже в вашей компании (интеграторе и т.д.) лично к вам будут вопросы от коллег, руководства. И примерно они будут звучать так:\
- Чувак, мы тебе платим деньги не за то, чтобы ты отклонялся от ТЗ. ТЗ, как и другие проектные документы - результат работы каких-то других людей. Аналитиков, методологов, возможно даже консульнатов. Вот они все, поработали, все согласовали. А ты, творчески не поняв суть, внезапно что-то там сознательно изменил. У клиента, кому мы это делали, теперь проблемы. А что будет, если ему сейчас минимум насчитают пеней и штрафов? Из чьей зарплаты это нужно вычесть? Из твоей? А ты уверен, что ее хватит?...ну и т.д.
Т.е. в сухом остатке, Автор, обращаясь к Вам, именно как Автору, резюмирую: где-то, вполне допускаю, что ваш подход допустим и даже полезен. Но где-то - это сулит вам проблемы, о которых Вы ранее, допускаю, даже не слышали, что у разработчика - они в принципе могут быть. Один раз вы обожжетесь на этом, и далее ваш поведенченский паттерн будет такой: если в ТЗ указано: 2+2=5, значит 2+2=5. Без вариантов. Т.к. возможно есть какая-нибудь 28/3 Глава НК, в статье 389 части 20 параграфа 8, в третьем предложении сверху, в варианте трактовки какого-то законодательного или исполнительного органа, и правда 2+2 = 5 для целей какого-то учета. Вы не знаете, правда это так или нет - но допускаете, что это правда так, и кодите спокойно себе это. И в случае любых предъяв с любой стороны, вы - лично Вы, в домике и не при делах. Вы можете возразить - да что за дела то? Не может быть такого! Ну и далее по логике вашей статьи. Повторюсь только: если Вам лично про это неизвестно, и Вас пока это все миновало - это не более чем Ваш опыт :)
Удачи в проектах!
И вот в этом мире — следование БУКВЕ (капс и болд здесь не случаен) ТЗ — ваша страховка в протоколе допросов по повестке. Потому что если в результате вашего "творческого осмысления" ТЗ, в котором было четко указано, что можно брать в качестве вычета по НДС, а что нет — получилось нечто иное, то разговор лично с Вами, поверьте — будет очень короткий. Если вы накодите по ТЗ, и в нем будет ошибка, в результате чего какой-то ваш клиент, или ваше предприятие, не доплатит того же НДС, либо налога на прибыль — как вы думаете, когда эту нитку раскрутят, к кому будут вопросы? К тому кто писал к ТЗ или к тому, кто его реализовал?
Ну так а кто вам мешает указать заказчику что ТЗ кривое и потом исправить его вместе с заказчиком? Ну вместо того чтобы писать заведомо неправильно работающий софт?
Если заказчик вместе с бизнес-аналитиком требуют использовать формулу 2*2=5 - роль программиста, в первую очередь, уметь сделать, чтобы случайно не получилось 2*2=4.99999. А так эта кроличья нора (до какого уровня погружаться в предметную и смежные области) очень глубокая.
а кто вам мешает указать заказчику что ТЗ кривое...Ну вместо того чтобы писать заведомо неправильно работающий софт?
Для того, чтобы понять "кривое ли ТЗ" или нет, в части регламентного учета, вы должны уметь во всякие НК, ПБУ, ФСБУ и прочее, на уровне человека с ходу отвечающее на вопросы в каком разъяснении и кого, как трактуется та или иная норма. Ммм...Мне кажется, на уровне разработчика - это не просто овер скилл, это уже сверх овер скилл, и если Вы таким скилом обладаете - не понятно, зачем Вы кодите? Ну т.е., часто (или всегда) вы понятие не имеете "кривое ли ТЗ" или "прямое". Если там поработали аналитики, методологи, консультанты и оно подписано с обоих сторон - самое разумное и правильное для вас - следовать его букве. Вы, естественно, имеете право подвергать любой пункт, любое утверждение - сомнению, но чем больше вы будете кодить подобного - тем меньше сомнений у вас будет появляться. В конце, вы прийдете к простой аксиоме, из моего кейса выше: 2+2 = 5. И это, кстати, может и действительно быть таковым в какой-то части чего-то там.
Так что, отвечая на ваш вопрос про кривизну - да ничто не мешает. Просто подвергнуть сомнению ТЗ в таком ключе - это значит погрузить во все это нормативно-справочное, законотворческое и разъяснительное пояснилово. Но на то уже есть соответствующие люди, и они, априори, и написали для вас это ТЗ, перемолов всё это для вас и за вас - а вам осталось только накодить. И софт в этом случае, не заведомо неправильный. Просто вы не погрузились в эту глубину настолько, чтобы понять, что все таки, он правильный :)
Ну так если вы не в состоянии понять что ТЗ кривое, то это одно. И никто от программиста не требует полного понимания предметной области.
Но вот если вы видите что ТЗ кривое, но при этом молчите и делаете по ТЗ… Зачем так делать?
Но вот если вы видите что ТЗ кривое, но при этом молчите и делаете по ТЗ… Зачем так делать?
Строители молча вышли из чата.
Как бывший "вышедший из чата, а сейчас смежник, приведу краткий диалог как пример:
С.- "Ребят, так низя, развернется и может ещё кого-нибудь покалечить"
З. - "иди нафиг, у нас тут дизайнер нарисовал, а проектировщики сказали что если сделать так и так, то всё будет ОК, делай как нарисовано"
С. - " блин, я конечно полные расчеты не делал, но в первом приблежении, вот в этих узлах нагрузки идут вот так, а в этих вот так, и просто по законам физики оно точно навернется. Пусть пересчитают, вдруг, где, ненароком, ошиблись?"
З. - "ЪЪ, ты чего умничаешь, умные люди считали, рисовали проект, чего разумничался, делай как нарисовано!"
С.- "Ну ОК, только вот здесь подпишите"
Через полгода:
З: - "Жеваный крот, уроды криворукие! Эта хреновина навернулась! Кот от страха впал в литоргию, собака ходит на ушах и дочка родила раньше срока! Вы мне бабок должны и восстановить все по гарантии"
С- "0_о, так я же предупреждал что точно навернется, а вот и подпись Ваша что делаем четко по проекту и работы по проектированию никто перепроверять не будет и Вы предупреждены что эта часть может разрушиться и это будет негарантийный случай"
З.- "да что вы блЪ за специалисты? Не могли нормально объяснить что оно навернется?"
Последние 2 пункта уходят в цикл.
А теперь по теме: большинство из нас считает себя адекватными заказчиками, НО, как правило, наши суждения о предметных областях, которые не являются нашими профессиональными, слишком поверхностны, и зачастую основаны на "экспертном мнении" "анонимусов из интернета"(неважно сколько у них лайков/подписчиков etc) и/или курения форумов - мануалов и т.п., но опять же, без практического опыта, эти знания/мнения практически равны нулю. Так вот, когда мы выступаем в роли заказчика, нам очень сложно принять тот факт, что мы очень мало понимаем в той или иной области (мы же умные, мы "изучали вопрос") и прислушаться к мнению и/или рекомендациям профессионалов. Из личного опыта: цепочка от меня до заказчика может быть как прямой (b2c), так и содержать 3-5 звеньев, в любом случае у меня есть. прямая связь с заказчиком и на этапе проработки итогового проекта проговариваются все возможные варианты улучшений/оптимизаций или необходимых изменений. Дальше 2 варианта развития событий: 1)подписывается договор "как надо и должно быть" или, если заказчик упоротый, 2) делаем договор "как хочет заказчик" и подробное приложение к нему, с максимально полным перечнем возможных недостатков. В такой ситуации получается "win-win",мы или делаем продукт отличного качества или выполняем чётко оплаченую работу (почти) без негатива со стороны заказчика.
Я не программист, а инженер.
Хорошо. Я поясню на конкретном примере, как у нас, в кроваво-слезном финансово-регламентном интерпрайзе обстоят дела с разработкой. От клиента прилетает такая постановка: мы ведем учет в софте Y и у нас есть в поле завод с производственными цехами. Мы возим туда рабочих на вахту на автобусах. Затраты на ГСМ этого автобуса - как можно принять в расходах эту затрату в части касающейся? Помогите "настроить"!.
Эта поставка уходит к методологу по НУ (Налоговому Учету). Это такой чувак, который знает примерно по пунктам и главам НК (Налоговый Кодекс). Его результатом работы будет развернутый ответ с выдержками глав НК, писем минфина, решений судов и пр. и пр. От его ответа будет зависеть первая часть вопроса клиента - так можно принять эти затраты в расходы или нет? Методолог, с полным нормативно-справочным обоснованием, указанным выше - отвечает, окей. Можно!
Далее, этот апрув уходит к аналитику/консультанту/бизнес-аналитику.Это такой чувак, который получив однозначный ответ от методолога, уже определяет как конкретно в клиентском софте Y, настроить этот бизнес-процесс. Он подробно отвечает на вопрос - как это делать, что настроить, что где включить, как внести и т.д. Сам аналитик/консультант не обязан знать ответ на вопрос - можем или не можем, но точно обязан этот ответ прочекинить в софте и показать как это делается. Если выясняется, что это сделать нельзя (просто нет такого функционала, новый закон, изменения и т.д.), а клиенту - нужно, он описывает ФР (функциональный разрыв), пишет под него некие функциональные требования.
Методолог и аналитики/консультанты входят в функциональную группу в проекте. И все функциональное проектирование делает как правило аналитик/консультант. Но оно к технической части никакого отношение не имеет, как там на архитектуру все сложится в итоге, это уже хлеб других людей: технических архитекторов, тим лидов, и т.д. В результате, до разработчика (программиста) свалится уже готовое техническое (частное) задание на разработку, в котором учтено результаты функционального проектирования и технического. И все что ему остается, это сесть - и это все разработать (написать). И вот и в статье, и в вашем комментарии, отмечается что в финальном задании для разработчика могут быть какие-то ошибки, которые он сам может заметить, ну и как-то на это повлиять. Действительно, такое может, сугубо в его технической части, если тим лид, архитектор, технический рп и тому подобное, просто упустил что-то в части архитектуры (ну или тупо просто не прав/не знает тонкостей). Конечно, именно в данном конкретном случае, разработчик, действительно обязан сообщить о косячке и дождаться, когда это изменение протащится и согласуется во всех проектных доках. Это разговор один. Но он совершенно другой уже, когда разработчик сообщает о косячке не в техническом проекте, а в функциональном. Это буквально означает то, что вся вертикаль в части функционального проектирования полностью провафлила что-то, и скорее всего, даже согласовала с заказчиком, получило его утверждение. Ну т.е. это что-то из ряда вон вообще выходящее, и если разработчик может на таком уровне в регл.учете ловить такие косяки - то первый и самый главный вопрос, почему этот человек до сих пор пишет код? Очевидно, что он это уже все перерос, и ему надо двигать выше. Но по своему личному опыту, по опыту коллег, такие продвинутые в предметке разрабы, если и встречаются в дикой природе, то это однозначно очень краснокнижные экземляры. Просто сами прикиньте, сколько и какого опыта у вас должно быть вне технической разработке, чтобы ловить методологов/консультантов на их ошибках? Это совершенный овер-скил. В нашей отрасли, думаю такое могло бы быть, если разработчик сидел на одном виде учета лет 10, и разрабатывал подобное несколько раз для разных клиентов в разных отраслях. Но в жизни, такое если и встречается, то очень редко. Сам кроваво-слезный проектный регламентный интерпайз, вам, как разработчику, не сильно даст время на что-то более, чем разработку по заданиям. И у вас всегда есть выбор - вы либо держите сроки (более или менее), а на это тратится все рабочее время, либо - вы барахтаетесь в предметке, пытаясь там что-то для себя пояснить. Это отлично, но надо понимать, что скорее всего - вы это будете делать за свой счет в нерабочее время, выходные/праздничные дни. А оно вам надо? Может кому и надо, но таких меньшинство. А в рабочее время, вы только будете таски в жирах закрывать. Там особо нет времени на раскачку.
Много написал, но думаю главную мысль донес. Вот это и есть кровь интерпрайза. Разработчик в нем - это чисто мозги и руки именно для разработки. Все проектирование делается за вас, для вас, чтобы вы могли сосредоточиться именно на разработке как таковой. Вам буквально за предметку вообще не надо переживать - главное в сроки с должным (более или менее) качеством реализовывать эти задание в коде. Как-то так.
Я так понимаю, Автор статьи, как-то этот момент не учел в своем повествовании :)
Спасибо за столь развернутый комментарий. Очень приятно видеть аргументированные позиции. Автор статьи в полной мере это учел, потому как разбирается в НУ, БУ, УУ, ПБУ и прочих "У". Позиция автора состоит в том, что любой предметной области можно научиться коль скоро ты за нее взялся. "Научиться" в данном контексте означает разобраться настолько, чтобы решить задачу методологически правильно (хорошо) и подсказать заказчику, что можно сделать лучше, чем он заказывал (идеально). Не так страшен черт как его малюют - автору в свое время приходилось разбираться в раздельном учете НДС, тонкостях учета растаможки товаров и прочих около ГТД-шных вещах и во многом чем еще. И ничего! - будучи программистом и не имея под рукой специально обученных людей, готовых подать тебе информацию на блюдечке, автор с этим разобрался в приемлемые для заказчиков сроки. Да, нужно уметь искать информацию, но благо заказчики всегда идут на контакт в этом и готовы общаться с тобой бесконечно долго, лишь бы ты их понял. Да и программист, по сути своей, человек интеллектуального труда (если он не техник) - залезть в консультант+, пообщаться с рабочими в цеху всегда сможет.
Отдельно подчеркну, что это ни в коем случае не исключает из проектов таких людей как аналитиков, методистов, архитекторов и других людей.
Проблема, затронутая в статье, это больше про инертность и закостенелость в позиции "Я - программист, дайте ТЗ". Такая монументальность останавливает тебя в развитии. Ты можешь быть сколь угодно крут в технологиях и "стеках", но если ты не можешь понять заказчика, то ты неизбежно проигрываешь своим коллегам.
В моей статье речь идет о развитии, об образе мышления, о том как стать лучше и самодостаточнее - приносить больше пользы людям!
Если программисту что-то непонятно, пусть переспросит лишний раз.
Вышестоящим этот его вопрос тоже может оказаться полезным, я как-то придумал нечто новое, когда объяснял проблему водителю.
Главное, чтобы когда оно таки провалится, кодера не сделали крайним. Как оно в кровавом энтерпрайзе с этим?
Специфика регламентного кровавого интепрайза в том, что там когда что-то "валится", то как правило клиент про это узнает только после того, когда ему приходит какое-то требование, либо аудиторы дали не очень позитивное заключение и подсветили какую-то проблему, которое "уже почти" требование. Т.е., когда посыпалось - боржоми пить в прямом смысле, поздновато.
А может и совсем поздно, в случае короно-кризисных выходных рабочих праздничных оплачиваемо-неоплачиваемых дней. Там вообще такие истории были: увольняют по сокращению, делают выплату. Человеки ушли. Сотрудников много, расчетчик в запарах не проверил полный расчет, а может и не знал как в текущих реалиях проверить. В любом случае, выясняется что некоторым бывшим переплата составляет где x2, где x3 от положенного. Соответственно, организация обращается к бывшим сотрудникам - дескать, ошибочка вышла, вертие ошибочно перечисленные. А те такие - чеееего? Давайте в суд, вы нас в короно-кризис вышвырнули на улицу, мы считаем - это компенсация. Соотв., в суде, судья у организации спрашивает - на каком основании вы сделали эти завышенные выплаты, привидите АЛГОРИТМ расчета вашего ПО на данных этих сотрудников. И далее начинает раскручиваться эта нитка - а это не мы писали, нам подрядчик писал, вот наши подписанные акты, вот наше задание, а сами мы не местные. Далее, несмотря на то, что в договоре с подрядчиком, естественно указано, что дефекты, в т.ч. и скрытые, ущерб и бла-бла-бла, не может быть предъявлен и все такое - может потребоваться экспертиза, что и кто накодил. на основании чего, а дальше дальнейшие суды и попытка истребовать клиентом компенсацию уже с подрядчика. Т.е. в этом кейсе, именно этом, конечно не думаю что подрядчик сам будет судиться со своим сотрудником в ключе - кто не так ТЗ понял, но сами понимаете. Работу придется однозначно сменить, если это не технический косяк. Если же, претензии к вам, как к организации, имеет не ваш клиент, а другие - то вероятность сходить именно разрабу по повестке, прям не нулевая, т.к. я надеюсь вы понимаете, когда дело доходит до такого, крайним быть никто не хочет. И, естественно, здесь просто железобетонный аргумент такой, что разработчик писал по ТЗ. Т.е. 2+2 = 5, и ему это по барабану, т.к. в ТЗ так написано, а разраб - ни методолог, ни консультант, ни аналитик, ни ПМ, ни тех.лид и т.д. перечисляем, кто он "ни". К Вам, именно при такой постановке = вопросов ноль, при условии что эти задания будут предъявлены. Поэтому, от греха, только от греха подальше, лучше все бекапить :)
Как все весело придумали.
Чего бы не добавить в качества программиста, ну, допустим, умение пользоваться фотошопом и блендером каким-нибудь, дизайн накидать там, ну, пусть еще и в колористику может, а то что он за профессионал-то? До кучи, пусть еще и разбирается во всех предметных областях, а то приходит заказчик такой, магазин автоматизировать по продаже футболок, а программист - не знает как бухучет вести правильно, чего ж он такого там напрограммирует? О, хорошо бы и законы всех стран знать, ведь кто знает откуда будет заказчик, а накодит там чего-нибудь, а потом инспекция придет и по шапке надает.
Вот если этого минимума нет, то какой вы программист-то тогда? Проходимец с курсов какой-нибудь.
Да, а если найдется такой вот настоящий ведущий, то платить ему 80к рублей в месяц, а то программисты и так жируют, иначе откуда столько курсов-то?
Если по тону сообщения непонятно - это шуточка. Программист, внезапно, должен программировать. Выяснять что там хочет заказчик - задача менеджеров и аналитиков. Если программист на себя берет их обязанности, то с разделением труда в конторе не все в порядке.
А потом это -> https://habr.com/ru/post/660337/
Я как-то был в командировке на одном небольшом металлургическом заводе и там эффективные менеджеры сократили технолога(ему же платить надо!) и на координатно- растяжном прессе его функции взвалили на оператора-программиста.
Ненуачо - он же работает уже 7 лет, должен уже все знать лучше любого технолога, он же программист(а на зарплате новая обязанность не отразилась совсем), вот пусть и вкалывает, а не за компухтером своим кофе пьет! А то что сопромат не знает - ниче, научится.
Оператор попытался написать технологические карты, и по ним работать - ничего не получалось, конечно, потом плюнул и стал работать вручную - на глазок.
Брак на оборудовании был - 100%, но директор приказал службе ОТК принимать все - в сборочном цеху доработают напильником и кувалдой.
В современном мире разработки чаще применяется подход agile, в котором роль ТЗ выполняет userstory, которая описывает виденье нового функционала далекими от разработки людьми, после этого userstory прорабатывается и делится на уже конкретные мини-подзадачи аналитиками, либо тим-лидами, либо мини-собраниями команды разработки (планирование-грумминг). Таким образом процесс подготовки ТЗ разделен на этапы, минимизирующие риски в реализации и сроках.
Задача хорошего программиста убедить заказчика выкинуть из ТЗ на 300 часов какие-то пункты, сместить ползунок от customer first в сторону code first подхода, чтоб меньше плодить сущностей, уместить это в 100 часов, но все равно сказать, что конечно же займет 300 часов. В итоге мы получаем ситуацию win win - проект не перегружен, заказчик всегда получает то, что требует бизнес, сроки не срываются никогда. Конечно кодить по 6 часов в сутки уже не получится, но думаю остальное перевешивает
нужно быть не просто человеком-печатной машинкой кода, а аналитиком.
Чтобы выдвигать такие требования, нужно раскошелиться на адекватную денежную компенсацию, а не как у нас, "конкурентная з/п 40 тыс. руб. в месяц".
В РФ программист (по крайней мере до недавних событий) даже без руководительских обязанностей мог без проблем зарабатывать и 400+ в месяц, и это работая в штате вбелую по ТК, я молчу о вариантах с валютной удаленкой
Конкурентная это 30к же. Так конечно, ведущим программистам не 40к платят, а больше. Это статья про то, что нужно уметь чтобы много зарабатывать
Ох.. ну да, наверное, вот такие формалисты есть в чистом виде, конечно, но это еще и может быть профдеформацией. Это лучше всего проявляеься на всяких легаси проектах, когда заказчику нужно вот тут и сейчас что-то сделать/пофиксить и он слишком жадный, чтоб всю архитектуру серьезно отрефакторить, а это неизбежно приводит в последствии к "а вот тут еще давайте...", "а вот здесь давайте тоже поправим..." и т.п. только в его понимании это все часть исходной задачи. Ну и посредники. Хуже всего, когда они пытаются честно себя выдать за реального заказчика, но понимают в проекте приблизительно ничего.
В свои фрилансерские годы всегда уточнял детали и пытался вытянуть из клиентов даже больше информации, чем они давали. И иногда, в таких случаях, проект действительно затрагивал косвенные задачи, но в итоге все были более, чем довольны. Когда познакомился с канбан -- вообще стал вести там проекты, при этом подключая клиентов к тем же доскам с кратким обзором как это работает -- очень удобно.
Сейчас у меня в стартапе вообще все с юзерсториз, спринтами, ежедневными конфами, с канбаном и диаграммами Гантта, с блокировками межу командами и все в таком духе -- очень эффективно.
Не представляю как по ГОСТам минтруда это все вообще может работать (и работает ли хоть где-то?)
На ком-то даже сработает.
Лучше конечно по возможности выяснять подробности, что и зачем делается. Однажды мне поставили задачу перенести данные между сильно различающимися конфигурациями 1С, я написал обработку, перенёс номенклатуру, цены, остатки, может даже приходные и расходные документы. Заказчик проверил и поставил следующую задачу: убрать из новой конфигурации старые операции, оставив только номенклатуру и цены... С тех пор я не очень люблю, когда задачу ставят по частям...
Но будет ли программист предлагать свои изменения в ТЗ, наверное в большой степени зависит от заказчика (работодателя). Как от личных качеств того, кто ставит задачи, так и от того, как там в целом выстроена система принятия решений.
Знаете, что больше всего выдает в вас низкоквалифицированного программиста?
Субъективное деление программистов на квалифицированных и нет, и написание статьи по мотивам? ;)
Никто в здравом уме программистов ни до общения с клиентами, ни даже до чтения ТЗ, согласованного с клиентом, не допускает. Это отдельная профессия, аналитик называется.
Да даже в плане менеджмента как вы это себе представляете? ТЗ же оно слишком большое обычно, чтобы один программист в обозримые сроки его сделал. Типа закинули в комнату с программистами ТЗ, ушли и ожидаете, что оно всё чудесным образом сделается? Его надо как-то поделить на задачи. Тот, кто это делает, конечно должен очень хорошо понимать бизнес. А тот, кто потом делает эти задачи, понимать бизнес должен только в небольшой степени
А зачем вообще платить менегеру, который переводит бизнес-требования в ТЗ, если донести до разработчика нужно бизнес требования?)
Может вам тогда нужен сразу программист-менегер, который услышав ваших хотелки, проведет кучу анализа и предоставит несколько путей решения, с точными сроками, стоимостью, возможными рисками. Можно заодно придумать план для вашего бизнеса на десятилетие вперед.
А вообще передавая разработчику ТЗ вы берете на себя ответственность, что выполнение этого ТЗ максимально дословно это и есть то что нужно бизнесу. Если вам нужны варианты и т.д. вам не к разработчикам, а к менегерам, это они может сами, а может беседуя с разработчиками могут выдать варианты.
А все остальное у вас это прикрытие бумажками одной простой хотелки, вы хотите сказать программисту "сделай хорошо". Не работает это по той простой причине, что у программиста есть очень много областей для развития помимо вашего драгоценного бизнеса. Он может туда влезть, возможно ему даже хватит смекалки сделать такой же забыв про программирование. Но он не станет. Программисты часто любят науку и абстрактные знания, поэтому вместо того чтобы изучать скучный вопрос "как мой бизнес зарабатывает деньги" он лучше почитает про новые технологии, открытия, физику, математику. Благо хватает бизнесов, которые понимают зачем человеку, отдавшему науке не один десяток лет, для общения с бизнесом нужен переводчик)
А зачем вообще платить менегеру, который переводит бизнес-требования в ТЗ, если донести до разработчика нужно бизнес требования?)
Может вам тогда нужен сразу программист-менегер, который услышав ваших хотелки, проведет кучу анализа и предоставит несколько путей решения, с точными сроками, стоимостью, возможными рисками.
Есть разные отрасли в IT, в том числе и именно такие. Когда нет ничего лучше чем чистые бизнес-требования с вариантами использования. Без каких-либо технических деталей, чистый UX.
К примеру ERP системы, где уместнее самому программисту создавать технический дизайн по ходу работы, и проактивно предлагать в том числе функционал. Но такая роль в индустрии только в обиходе называется программист, а более формально это технический консультант как к примеру Senior Development Consultant.
Вот тут классификация по канадскому NOC более уместная чем "программист", "программист плюс": https://habr.com/en/post/660339/#comment_24261811
Всё так если не брать в расчёт разработку по фикс прайсу. Есть и конторы и фрилансеры которые работают по такому принципу, и там если даже ты заметил что клиент хочет дичь, а чтобы сделать нормально нужно больше времени, то может быть себе дороже ему сообщать о проблеме.
ИМХО это отличная идея взять сеньора в штат и сказать ему "сделай хорошо", но не у всех есть на это деньги.
Не согласен с автором статьи и как доказательство ролик с ютуба "Дубляж британской короткометражки "The Expert" - https://youtu.be/UoKlKx-3FcA
к несчастью ни одного заказчика, который бы не попадал в это видео - мне видеть не доводилось.
Всё -таки задачи бизнеса решает начальник программиста. Программист же не в вакууме работает. У него есть начальство, которое кстати говоря больше этого самого программиста получает. Как раз за то самое, чтобы задачи бизнеса согласовать с кодом. А вовсе не за то, чтобы просто передать вниз приказ вышестоящей инстанции.
Программист, который работает за деньги а не за идею, ИМХО будет предлагать поправить ТЗ только в случае, если есть возможность сэкономить свои силы. Или там уж совсем лютая дичь, а к заказчику есть симпатия.
Так вовремя поправить тз — это сэкономить силы на сдачу работ.
за поправить ТЗ вам не платят.
За поправить код - вам платят, более того, вы уже думали и может даже заложили фундамент для этих правок.
Ваше руководство (не всегда) тоже в плюсе. возьмут как за полноценную работу, а сделаем - за половину времени.
Я понимаю, что подход - такой себе. Не на уровне "насрем себе в штаны", но где-то рядом. Но если помогать всем бесплатно (решать за других их проблемы/обязанности), на штаны просто не хватит.
Тезис: "вы плохой программист если просто следуете бумажке по пунктам". Доказательство: "смотрите, вот вам бумажка, в которой по пунктам написано что надо делать чтобы быть хорошим программистом". Ирония
«нет в ТЗ – идите мимо»
Знайте, если вы так делаете, то вы низкоквалифицированный программист-техник, не больше!
Бывают случаи, когда приходит "одаренный заказчик" с крайне низким уровнем технической грамотности, и у меня закономерно появляется очень сильное желание побыть 5 минут низкоквалифицированным специалистом. И порой результаты этих 5 минут оказываются куда продуктивнее нежели 2 предыдущих часа разжевывания материала.
Но это частный случай. Статья интересная, однако написана с явным перегибом....
Статья скорее про рост в профессии, а не про то, что все кодеры должны понимать желания бизнеса, но акценты расставлены криво.
В целом бред, так вы путаете управление , аналитику и разработку. Ваше правило работает если в процессе участвует два человека: заказчик и исполнитель. Но чем больше команда, тем больше необходима формализация и разделение обязанностей.
Понимание процессов на уровень выше, чем в ТЗ, не относится к программированию. К этому можно, и скорее всего нужно придти. Но говорить, что человек, который сделал все по ТЗ - некомпетентный и низкоквалифицированный, это неправильно. Некомпетентность проявили в данном случае заказчик и составитель ТЗ.
Если он не может ничего больше, то он не некомпетентный, а низко квалифицированный. АКА джун АКА техник-программист.
А платят ли за проект по рейту высококвалифицированного специалиста, значительно выше рынка, с учётом его способностей к анализу бизнес-задач?
В статье затронут стандарт на джуна, мидла и сеньера как их видят в министерстве.
Соответственно, всем всегда платят по рынку.
Только техникам по рынку джунов
Ведущим — по рынку сеньеров.
Чушь. Полная чушь. Видение министерства настолько оторвано от рынка, как и ваши представления о том, сколько кому платят.
Особенно если рассматривать не только локальный рынок, но и международный.
Может, в государственных структурах и разных банках своё видение, но никто не заставляет работать именно там, именно на их условиях. Если говорить о рыночной цене (медиана) - то, в целом, несложно менять одну работу на другую, один проект на другой без ущерба для своего кошелька.
Если заказчик хочет анализа его ТЗ на соответствие бизнес-задачам, но не хочет платить за это, то стоит подумать - а оно стоит того? Ну или выставить за отдельный прайс или коэфициент, дескать, если я ещё буду аналитиком, то цена будет выше. Хотите дешевле, как по рынку, - предоставьте нормальное ТЗ.
Как это будет соответствовать каким-то бумажкам министерства - вообще не важно. Это министерство ничего не сделало для развития IT в том виде, в котором оно есть сейчас. Оно пытается только что-то там стандартизировать и подогнать в рамки, но это проблемы министерства и гос. учреждений, а не программистов, и уж точно не проблемы международного рынка IT.
Вы до потертости пальцев будете тыкать в ТЗ, говорить, что оно утверждено и подписано заказчиком. Что он сам виноват в том, что не углядел/не дописал, а теперь топает ногами и требует, чтобы вы доделали работу, но никогда не признаетесь, в том, что не смогли здраво оценить свои силы, потому как некомпетентны.
Знайте, если вы так делаете, то вы низкоквалифицированный программист-техник, не больше!
Очень сильно это зависит от того, кто кому и сколько платит. И стоит ли оно того.
Одно дело - иметь долю (акции) в компании и быть прямо заинтересованным в её успехах. Или щедрое вознаграждение здесь и сейчас, желательно с прозрачными перспективами дальнейшего роста.
Совсем другое - просто делать свою конкретную работу за конкретную зарплату или контракт и не морочить себе голову не своими проблемами.
Будем честными, в IT - своя атмосфера. И айтишникам она предоставляет больше свободы, чем в других. Почему бы ею не пользоваться? Можно хоть обложиться ГОСТами, но почему-то не упоминают, что всё это стоит нервов, здоровья и сильно зависит от человеческого взаимопонимания. Иной раз проще уйти в другую компанию или найти другого заказчика, чем что-то кому-то доказывать.
Ну на хабре формалистов нет - https://habr.com/ru/post/340052
тут все знают что нужно заказчику без всяких там тз и фидбеков )
Когда ТС подписал ТЗ не глядя и его жестко нагнули, втуляет теперь бред какой-то.
Я инженер-конструктор, там где я работаю мы делаем ядерные реакторы, и мне очень близко всё то, о чем вы написали, только в разрезе конструкторской работы. Можно я возьму за основу ваш текст и перепишу его слово в слово, только в своём контексте?)
Знаете, что больше всего выдает в вас низкоквалифицированного программиста
Скорее просто определенный класс профессии. 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.
статья не затрагивает один в наше время важнейший вопрос "А заказчик готов оплачивать работу ведущего программиста и решение всех задач, не вошедших в ТЗ?".
ТЗ - зона отвественности заказчика (всегда).
ТЗ - это едва ли не более 50% от успеха решения поставленной задачи.
Зачастую получаем ситуацию, в которой куча работников заказчика готовит вместо ТЗ "филькину грамоту", а потом возникает наезд "вы посредственный программист", "вы должны были поработать за нас". Так может программист должен работать за заказчика и заказчик должен оплачивать работу вместо выплаты зарплаты, давайте говорить открыто, дармоедам?
Один из моих УЧИТЕЛЕЙ рассказывал как такую ситуацию "разрулила" польская команда программистов и системщиков, когда по ходу работы по развертыванию MES и ERP на предприятии выяснилось, что помимо типовых задач они должны проанализировать все технологические и бизнес процессы, составить план поэтапного внедрения указанных систем и внедрить их безударно. ТЗ этого не предусматривало. Бюджет был зафиксирован, о его изменении заказчик разговарить отказался, более того еще и кидался фразами про некопетентность и т.п. Итог закономерен: на всех страницах и отчетах MES и ERP, которые не предусматривались ТЗ выходила фраза "jak płatne i jak to się robiа" (перевод сами найдете).
С момента внедрея указанных систем прошло 15 лет и год назад меня приглашали на их "модернизацию" (термин согласно очередного ТЗ). Так вот, до сих пор эта фраза выводится на экран и бумагу. И, судя по всему, будет выводится до полного сноса Систем, т.к. этот опциональный функционал заложен на уровне базовых модулей и приложений. Как вы уже догадались, в ТЗ нет ни одного слова о том, что необходимо не просто модернизировать Системы, а переписывать их с нуля (ну или править на уровне ассеблера, ведь исходников кода все равно нет).
У статьи или у ее автора однобокий взгляд,
в котором программисты (и тем более, их квалификация) всенепременно связаны или должны быть связаны с "бизнесом".
Либо, подразумеватся всенепременное сущестование "заказчика" А это совсем не так.
Таким образом, ложна сама исходная посылка.
Примеры:
Квалификация программистов Open Source ПО.
Квалификация программистов DemoScene.
Квалификация программистов в институтах или заводских государственных КБ (создавших ПО для космической техники, например "Буран").
Ко всему прочему, имеются большие вопросы к понятию "квалификация программиста". Вот, например, товарищ "А", всю жизнь писавший текстовые парсеры-компиляторы, способный за день наваять вполне действующий язычок. Но ничего не понимающий в 3D с его матрицами, векторами, shading language и ассемблером. Посади его за 3D, он будет барахтаться пару недель. А может и вообще не выплыть. Вообще никак. То есть результат ноль. Таким образом, его производительность в несвойственной ему области снижена раз минимум в 15, а то и более. И это еще не считая того времени ккоторое он будет убивать на чтение дома (не в рабочее же время ему читать книжки и материалы). А вот товарищ "Б", всю жизнь ваявший 3D, способный запилить +- быструю сценку/3D редактор в режиме хакатона примерно за день. Посади его писать парсер-компилятор - и внезапно, минус тех же пары недель (если не больше) и все только ради того чтобы на выходе вышел корявенький-прекорявенький первый пробный шар. Со всеми вытекающими проблемами, шаг влево, шаг вправо - расстрел требуется еще время. А может и снова, ничего не выйти (т.е. потребуется время x30...x60).
Налицо, производительность сниженная от ~15 раз по сравнению с первым. А вот третий товарищ "В", Embedded программист, двадцать пять лет шатавший электронику, FPGA и микроконтроллеры, имеющий понятие о схемотехнике и последствиях связи программного и физического (эл. процессов). Ни парсер языка, ни 3D не потянет. Ваяет на простом СИ, без ООП и функциональщины, паттернов и проч, о которых никогда не слышал. Но вот вопрос - если посадить первых двух, какая там "электроника" получится на выходе? И затянуться может также не x15, показатели x45...x60 легкодостижимы.
Так что "квалификация", это очень спорная вещь. Связывать с ней что попало я бы не советовал. А также по дуре считать что для решения некоторых задачи всегда всенепременно требуется сверхбог способный и в различные языки, и в ООП и в фукциональщину, и электронику, и математику, и инжиниринг, и сети, и linux OS-программирование, и культуру разработки, и проч, проч, проч.
Аналогично, инжиниринг ПО и менеджмент (процесса создания ПО) это разные вещи. Не надо их связывать. Хотя для срачегенерирующего кликбейтного заголовка-красной тряпки на что только не пойдут.
Лонгрид на тему выживания ремесленника а-ля компьютерная помощь. Давайте начнём с того, что высококвалифицированный программист занимается внезапно программированием. А вот все эти постановки задач,анализ бизнеса, дело команды продукт менеджера или фидбэк от отдела тестинга маркетинга и так далее, опять же пропущенные через менеджеров и нарезанные на спринты.
ТЗ должны писать вы!
Если заказчик приходит с ТЗ, то ваша задача обработать это ТЗ так, чтобы оно действительно соответствовало настоящим целям заказчика и было при этом реализуемо. Итогом этой этой работы должно быть ваше ТЗ, основанное на ТЗ заказчика.
Если заказчик не хочет ничего менять в своём ТЗ даже если вы видите недостатки в этом решении и указываете ему на них, то лучше откажитесь сразу. Поверьте, это сэкономленные нервы, убитое впустую время, и, как итог, попадание на деньги.
Согласование возможных дополнительных работ нужно по максимуму проводить заранее. Какой-то минимальный их объем лучше всего сделать бесплатно, но при этом очень чётко объяснить заказчику, что это ваша скидка хорошему клиенту, а не обязанность. Ведь ваша задача - не выполнить ТЗ, а добиться достижения целей заказчика, которые он хочет реализовать при помощи этого проекта.
Если к вам на автосервис придёт заказчица и скажет, что надо поменять колодки, потому что её красненькая лапочка стала плохо тормозить, а вы увидите, что надо срочно менять и тормозную жидкость, вы сделаете только то, вам дала в ТЗ заказчица? Нет, конечно. Надо убедить человека сделать все необходимые работы, тем самым сформировав новое ТЗ на колодки и жидкость.
Знаете, что больше всего выдает в вас низкоквалифицированного программиста?