Программа это технология, которая должна долго оплачиваться и значить больше инструмента.

Программа это вершина мира технологий. Потому и Информационные Технологии.

В каждой пограмме есть спецификация или теребования. Их надо знать всем кто относится к программе. Клиентам, заказчикам, связанным директорам ИТ, техническим писателям, проектировщикам, системным аналитикам, программистам, тестировщикам, менеджерам персоонала и т.д. Каждый должен знать на своем уровне. Поэтому работы очень много и оплата должна быть соответствующей.

Подумайте сколько надо знать сотруднику из того что я написал и сколько надо платить. А то инженеру платят столько же сколько шкльнику который прошел курсы. Не забывайте что инженеру надо помнить весь курс школы и института и технологию продукта, технологию работы предприятия, свои обязанности, технику безопасности труда, свою работу которая выполняется с НЕ ПОЛНЫМИ РАСЧЕТАМИ(или вы думаете что двигатель можно полностью обсчитать), помнить как себя успокоить после работы, помнить стандарты, помнить порядки передачи в другие отделы или ОТК. Голова пухнет, а платить никто не хочет. Так и в ИТ. Разработай им быстренько технологию и ничего не получи.

Времени на технологию наши деды тратили очень долго и это был подвиг. А что у нас? Слепили нам за двадцать лет IDE -шку не полную и все думают что программы-технологии напишутся сами по себе. Думаете ИИ не технология которая врет, как теория вероятностей в картах.

Но ИИ технология и она еще долго будет разрабатываться, поэтому радуйтесь молотку с коротким остовом. И не надо нервничать просто надо брать плату за проект как за сервис, а не дешевую рабочую силу которая строит шалаши.

Поэтому подумайте о том чтобы программисты как тестировщики думали о качестве. Как в принципе и другие специалисты в вашей кампании.

Каждый проект имеет жизненый цикл. В этом цикле версионность превратилась в итерации или в повторяющиеся шаги. Поэтому при работе программиста:

1. Нужно почитать летопись проекта.

2. Нужно почитать требования к Программному Обеспечению.

3. Посмотреть все диаграммы которые написали при проектировании (хотя-бы те которые относятся к требуемой функциональности)

4. Сходить к проектировщику, стстемному аналитику, архитектору.

5. Сходить в отдел качества и спросить тестировщика проффесионала, что работает в кратце (что помнит за-одно исправить что важно для отдела качества на сколько возможно-у вас задача в конце-концов сделать продукт, а не залепить ЧТО-ТО).

6. Если все сложно написать эскиз для будующей документации.(На сколько хватит творческого полета) Желательно с UML блок-схемой.

7. Написать спроектированную функциональность с заглушками и функцией авто-теста, причем так чтобы проектирование системы позволяло сделать авто-тест.

8. Проверить срабатывание авто-теста.(Тест поведения)

9. Реализовать все заглушки.

10. Проверить чтобы в продукте заработали все внесенные изменения!( хотя-бы раз)

11. Написать замечания о ограничениях алгоритмов и функциональностей(хотя бы в-общем).

12. Перевести задачу в отдел качества и сделать себе пометку что ждете ответа по ВАШЕЙ РАБОТЕ. (Не забывайте что если все не взлетит в релизе то вам могут перестать платить)

Если вы сделаете по всем пунктам и запишите все этапы и проблемы то у вас будет возможность попросить чтобы вам не снижали зарплату.

Это КУЛЬТУРА ПРОГРАММИРОВАНИЯ. Из такого отношения к работе наши деды сделали технологию ракеты. На которой полетел Гагарин.

За технологии ДОЛЖНЫ хорошо платить!