Работаю прогером 1С, но как это часто бывает, приходится выполнять кучу разных задач. Решил написать основные "предписания" работы ИТ отдела, чтобы не было хаоса(во многих компаниях так оно и есть) Если есть чем дополнить, милости прошу. Приму к сведению, и дополню "предписания")


1. Добиваться от пользователей четко сформулированные задачи к ИТ — отделу, с ТЗ(минимум описание).
2. Документирование инфраструктуры: карта сети, взаимодействия программ, маркировка кабелей, структура сервера, расписание и описание бэкапов, обменов, скриптов, заданий и т.д.
3. Хранение документации оригиналов, и копий оригиналов(можно в электронном виде) в одном месте: IP телефонии, интернет обслуживания, хостинг, программы и т.д.
4. Хранение паролей пользователей.
5. Информация об организации работ в регионах(подключение, общий доступ к ресурсам, сеть).
6. Порядок структуры файлов на сервере(чтобы файлы хранились строго в положенной папке).

Пункт 4 выкини

(0) Главное правило ИТ-отдела - в пятницу не делать ничего важного :)

(0)
7.Перестать заниматься хнёй и чужой работой.

(2) Однозначно. Иначе в выходные придётся поработать

3 редакция ИТИЛ возникла необычно, из флейма...

(2) (4) , Это уже народная мудрость)

(2) Первое правило ИТ-отдела - не говорить об ИТ-отделе
    Второе правило ИТ-отдела - не говорить об ИТ-Отделе.
    Третье правило: если вы впервые в ИТ отделе, вы обязаны
    чётко формулировать свои мысли

(2) верно - шоб никаких революций в пятницу.

Да! Вот часть 3, пункт 3, подраздел Б. "Обязанности артиста ансамбля". Выступать в единой для каждого коллектива утверждённой концертной форме. Выходить на эстраду в порядке, опредёленном руководителем. В процессе работы следить за качеством и умеренным звучанием инструмента. Осуществлять мероприятия повышения идейного и теоретического профессионального уровня.

Запрещается: Самовольно уходить с эстрады по каким-либо причинам кроме оказания медицинской помощи. Ходить по залу ресторана...

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

(0) пункт 4 выбрось и больше ни кому ни когда не показывай.
еще нужно, чтобы:
7. Вся работа с пользователями на тему технической поддержки велась через helpdesk. Ни каких позвонить по телефону и потрахать мозг айтишником. Любое обращение - это номер. Нет номер - нет задачи - нет работы.
8. Итили, кобиты и прочая полюбень - это круто и клёво, но работу в конченом итоге делают всегда люди, а не эфемерные сервисы. Надо это всегда помнить и на это ориентироваться.

(10) для революций лучше всего подходит предпоследний рабочий день апреля.

(0) Пункт 1 неверный. Превращать пользовательские хотелки в "четко сформулированные задачи" — это, среди прочего, работа ИТ отдела.

(1) (11) Чем 4 пункт не нравиться? Я ведь не буду оглашать это всем и всюду... "Я знаю пароль, я вижу ориентир")

(11) Helpdesk кстати, хорошая вещь, можно как альтернативу Битрикс 24 использовать

(0)
> 1. Добиваться от пользователей четко сформулированные задачи к ИТ — отделу, с ТЗ(минимум описание).

Хе-хе

(14) пароль должен знать только владелец пароля.
Это первый принцип безопасности

(16) От пользователей было бы неплохо добиться хотя бы четко сформулированного потока мыслей

(14) это дыра

(17) (19)Т.е. администраторам это по сути тоже не нужно, ведь в случае утраты или просто забыли, проще поменять?

(20) Конечно

мдя... 2017-ый на дворе и на орбите во всю е..тся спутники - а тут кто-то пытается сформулировать правила работы в виде документируйте системы, сервисы и инфраструктуру...

вас не замораживали лет на 20?

на практике не нужны пользовательские пароли, по пункту 1 пусть не ТЗ но хотя бы внятно формулировали задачи, а то бывает несут полную ересь

(0) Не показывать свои другие умения, не высказывать сомнительные навыки и знания. Например - взлом паролей.

(22) 8 из 10 компаний на это клали. Много ресурсов требуется для этого...

(23) А что сейчас уже все само?

(26) к (22)

(14) >Чем 4 пункт не нравиться?

внутренняя СБ по IT за подобное обычно руки выдергивает накуй

(28) Какая внутренняя СБ? в конторе наверно чел 10-15 работает.
Ну максимум 50

(25) 8 из 10 ларьков.

в конторах покрупнее и где на компах не косынку раскладывают таких вопросов даже не возникает

Делай бекапы!
Всегда делайте бэкапы!
Сперва Бэкап, а потом работа!
Система работает - не трогай систему.
Пользователь всегда врёт.
Не меняй пароли, после второго литра пива.

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

(30) Контора в 500 человек, в которой меня хватило на 2 месяца. Хранили и пароли и СБ есть, и сетевые кабели не маркированные и вообще хаос. Конторка региональная...

(33) 500 юзеров?

(32) Это не правила, а "правила". "Если забросить огород, он зарастет!"

(34) Не, юзверей поменьше было)

(35) Если для огорода правила писать, то да, зарастет.
Им заниматься надо.

(37) Инструментов и правил ухаживания за огородом нет?
Может дать тебе ЛОМ, и сказать "Иди копай"

(38) Чукча не читатель, чукча писатель! (с)

(14) Зачем хранить пароли пользователей?
Чтобы напоминать им если они забудут его?
Ну так если он его забыл не проще ли новый пароль ему сделать и не париться с хранением?

Из всего вышеперечисленного полезно:
1. Главное правило ИТ-отдела - в пятницу не делать ничего важного :)
2. Не хранить пароли
3. Делай бекапы!
Всегда делайте бэкапы!
Сперва Бэкап, а потом работа!
Система работает - не трогай систему.
Пользователь всегда врёт.
Не меняй пароли, после второго литра пива.

(14) вообще всем не нравится

+(41) не делай бэкапы туда где лежат данные (физически)

1. Разделяй и властвуй.
Смысл: дели большую задачу на маленькие и решай их по очереди. Однако помни о задаче в целом: все маленькие решения должны в конечном итоге вести к решению большой задачи.

2. Read The Fucking Manual
Смысл: вы должны уметь взлетать высоко и нырять глубоко. Уметь увидеть задачу в целом и уметь разобрать её до мельчайших деталей. Без системного мышления и аналитического склада ума в программировании делать нечего.

3. Зри в корень.
Смысл: например «директор» — это не человек, это должность, которую может занимать человек (а может никто не занимать). И «Иванов Пётр Сидорович» — не человек, а фамилия, имя и отчество, то есть атрибуты человека. Человек — это тело, живое или мёртвое, с кучей атрибутов :) Обычно до таких нюансов при проектировании не опускаются, поэтому большинство автоматизированных систем управления очень негибкие.

4.Программный продукт, моделирующий некую предметную область, физически не может быть проще этой предметной области.
Смысл: увы, никто не выделит вам ресурсы на поиск ответа на «главный вопрос жизни, вселенной и ваще». Ищите компромиссы между желаемым и возможным.

5. Если рассмотреть проблему достаточно внимательно, то вы увидите себя как часть этой проблемы.
Смысл: а вот не скажу :) Это правило из тех, до которого нужно дойти самому, своими ножками, иначе его не понять. Но вот когда дойдёте до него, будете удивлены тем, как можно решить нерешаемые проблемы простым, но очень необычным способом.

(43) А еще не ссы в штанину )))

(40) https://sklivvz.com/content/blog/your-password-is-incorrect.jpg

(0) Самое главное не забывать, что не организация для IT, а IT для организации.
И уметь правильно забивать на IT принципы)

Вот еще одно золотое правило - ПВО (погоди выполнять отменят), то есть любую работу надо делать без спешки.
https://youtu.be/23fBoqQxSgQ

(44) >4.Программный продукт, моделирующий некую предметную область, физически не может быть проще этой предметной области.

шта?!.. любая модель всегда проще того, что она моделирует

(0) Ублажать бизнес

правило трех гвоздей только надысь проскакивало

пункт 0 вовремя получать зарплату ))))) желательно с премией

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

запрет на хождение в ит отдел.
   все обращения в письменном виде


ит сами опросят и уточнят  нужды в переговорной .

(44) Отсыпь, а?

(12) Не, прямо перед долгими праздниками революция это худший вариант. Над проблемами, вопросами с срочными хотелками лучше работать по горячим следам, когда много еще в голове и ты погружен в задачу. За праздники это частично выветрится. Да и пользователи соскучатся по работе, а если нет, то точно соскучится их начальство с волшебными пенделями.

Но как из всякого правила, тут есть исключения.

1. Речь идет о революции в бухгалтерской подсистеме. Мне помнится, что там конец апреля последний срок сдачи кучи важных отчетов. Надеюсь, я не ошибаюсь, лет пять уже плотно с бухгалтерией не работал. После этого дедлайна вносить свежую струю самое оно.

2. После революции требуется массовая забивка, сверка и перепроверка входных данных, под которые выделены ресурсы в виде сотрудников предприятия.

Я как сейчас помню, когда первый раз столкнулся с таким подходом. На мой вопрос заказчику "Что будет делать со вводом остатков?", последовал быстрый ответ, что автоматизировать не надо. У нас тут 30 человек по всем комнатам, мы организуем плановый и массовый выход в субботу по всей форме. И они все заколотят, заоодно и спросить за ошибки будет гораздо проще, т.к. все персонализировано и находится в сфере заказчика.
Сказано - сделано! Я в летнюю пятницу все обновил, пожелал сохранять бдительность и не терять надежду на лучшее. Затем удалился на шашлычок под коньячок, а заказчик всей спецбригадой засел колошматить входные данные.

(56) Ты убил проект на этапе ввода в эксплуатацию. И кто ты после этого?

(57) молодец он, уболтал всех поработать, а сам на шашлычок

(57) Кто я, у меня в личке написано.
И ничего я не убил, это был один из лучших проектов. Дама от заказчика, принимавшая такое решение, была весьма толковой, отличный союзник внедрения. И организация у них была на высоком уровне. Входной потом в 30 пар рук сформировали махом и с минимальным уровнем косяков, без критичных.

крутой, чо

(59) "Входной" // это что?

(61) Входной потоК. Опечатка у меня.

(44)  самое толковое в ветке...

главное правило любого управления-это разграничение зон ответственности и обязанностей


по существу начинать надо с Разграничение ответственности. Системный администратор - Программист 1С пост 38

(63) как-то невнятно про обслуживание БД, а так неплохо расписано...

(0) > основные "предписания" работы ИТ отдела

Вот мои правила:

1. ИТ-ишник должен уметь читать мысли пользователей, угадывать их пожелания и на любое их «бе-бе-бе» выдавать нужный документ с вопросом, не это ли хотел / имел в виду мистер / мисс Пользователь?

2. Пункты 2-6 практически те же, разве что чуток улучшить их структурирование и расширить круг собственных обязанностей.

3. Уметь генерировать полезные для фирмы собственные идеи в области оптимизации учета и организации работы.

4. Иметь 100%-но собственные либо близкие к этому работающие конфигурации 1С.

5. Писать полезные статьи о своей работе.

В принципе, пока хватит.

(65) форум телепатов находится в другом месте

(66) Форум телепатов здесь, просто иногда телепаты в отпуске.

(0) Если ты работаешь программистом 1С, но тебе дали задачу написать правила работы всего ИТ-отдела, то напиши и на этом фоне проси прибавки к зарплате и повышения должности до начальника ИТ-отдела. Конечно, твоя ответственность тоже увеличится.

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

1. Не реально.
2. Нужно и важно.
3. Все это входит в п.2
4. Не нужная и вредная затея.
5. Повтор п.2.
6. Порядок он нужен везде.

Подытожим - п.2 дельная мысль, все остальное полная бесмыслица, повторы и растечение мыслью по древу.

(65) Можешь смело избираться в депутаты!

(71) > Можешь смело избираться в депутаты!

Осталось самая малость, получить гражданство России :) .

(72) В свои, свои давай там выбирайся. А то, как жизнь наладить, все досконально знают, но почему-то налаживать всех в Россию тянет.

(73) > В свои, свои давай там выбирайся.

Да можно и в свои, только здесь технарей не хватает, спецы все уже уехали в Россию. А поскольку удовольствия от технической работы больше, чем от гуманитарной, то большего эффекта можно достичь, адаптируя российские конфигурации 1С под законодательство ЛДНР (вместо украинских, как все делают).

> А то, как жизнь наладить, все досконально знают, но почему-то налаживать всех в Россию тянет.

Меня не тянет. У вас хорошо и без меня получается. А вот реально поработать технарем в России я был бы не против. Впрочем, для этого мне ничего не надо, кроме времени.

(74) Приезжай, чо

(75) > Приезжай, чо

Спасибо, готовлюсь. Вот закончу СПК (самоповышение квалификации), тогда можно думать всерьез. В свое время работал в Белгороде в НИИ четыре года, учился в МГУ на дневном пять лет, но в Украине развитие пошло немного не туда. Поэтому нужно подтянуть свой уровень под современные российские реалии, да и здесь какой-нибудь приличный результат после себя оставить. Теоретически можно работать через интернет, но пока и банковская система у нас никак не связана с вашей да и, как говорил, готовность еще не 100%-ная.

(76) Думай, чо.
Лично я новым программистам 1С всегда рад. Сам ищу сейчас программиста. Есть вакансия.

(77) > Есть вакансия.

Здорово! Но пока воздержусь. Привык работать квалифицированно, но российское и законодательство и бухгалтерия с налогами и конфигурации 1С сильно отличаются от наших. До сих пор мне хватало самописных конфигураций, но с этим у вас делать нечего. Нужно знать ваши типовые, теорию и практику. На все это у меня есть сотни часов видео (Гилева, Бурьяненко, Насипова и многих других) и гигабайты соответствующей литературы. Успешно осваиваю, но процесс не закончен. Так что лучше уж стать готовым специалистом, чтобы не портить впечатление о себе.

(0) 1) Если бы я 3 года работал по ТЗ, я бы так скорее и остался наборщиком кода, а когда крутишься и надо быстро и что бы не тормозило, стараешься любой механизм продумать как минимум на 2 а то 3 доработки вперед. Без ТЗ - это стрессовое быстрое погружение в процесс, когда с ТЗ - это всего лишь намочить пяточки. Из свежего, в холдинг входит новая компания, необходимо сделать перенос из их базы (совершенно левое какое то локальное веб решение), запустить в нашу, настроить, и цитирую: "надо что бы они работали у нас, по нашему учету, но вели учет как вели раньше", срок 01.08, задача от 21.07, выделен 1 исполнитель. И я уложусь в срок. Бизнес растет быстро и агрессивно и просто на бюрократию времени нет. Хотя ТЗ да, прикольно.
2.Документировать надо, но что делать если под это не выделяется время, просто приказ сверху на эту ку..ню время не тратить?
3) Да
4) Полное убийство какой либо безопасности. Если пароль потерялся - скинуть. Никаких хранений паролей в открытом виде...
5) Да.
6) А зачем вообще хранить файлы? У нас мы столкнулись с тем что уже просто обращение к файлам на диск начало занимать большое время (>1 ТБ небольших файлов), Засуньте всё в базу данных. MSSQL, MongoDB, это то что ковыряясь в носу интегрируется с 1C за вечер и на таких массивах работает как минимум на порядок быстрее, на тесте от 10 до 100 раз разница была быстрее.

Есть еще такое правило:
любая задача перед выполнением должна отлежаться некоторое время - часто бывает, что после этого надобность в ней отпадает. )))

(79) "срок 01.08, задача от 21.07, выделен 1 исполнитель. И я уложусь в срок" // Расскажи, как с точки зрения конфигурации это все будет (в твоем плане) выглядеть

(80) Кстати да, систему 3х гвоздиков никто не отменял. (81)
1) Заведено 2 новых элемента справочника, вокруг которых формируется в принципе весь расчет (сейчас их 3) (забыл написать еще идет переписка конфигурации, и обмены в старую базу, где еще половина сидит по минимуму должны меняться).
2) Допинаю завтра ответственного с их стороны по выгрузке (переносятся не только сущности, но и большое количество файлов)
3) Состав полей, формат в котором они придут и структура данных приблизительно известна (анализ по скриншоту), сделаю рыбу загрузчика.
4) Создам подсистему для этой организации, куда вынесу необходимые существующие объекты метаданнных.
5) Добавлю 2 регистра, для учета тех данных, которые у нас не ведутся, но ведутся у них, соответсвенно права и формы покррасивее сделать.
6) Добавлю 4 новые роли, настрою их, зарисовка по правам есть приблизительная.
7) В существующие документы добавлю команды печати уникальных печатных форм, ну и естественно настройка прав на эти команды.
8) Так как печатные формы красиво сверстаны в ворде, а подсистема печати еще практически вся в старой конфигурации - перенесу ее всю и немного модернизирую (2 справочника, 2 регистра + настройка прав + небольшая переписка механизма, давно хотел - руки не доходили)
9) Поправлю верстку вордовских шаблонов.
10) Жесткое ограничеение видимости - одно из условий. Проверю работу РЛС загруженных данных. Для корректной работы потребуется не просто залить данные из их базы, но и создать сущности, переноса которых нет, но они нужны для РЛС
11) Вместе с разработчиком обмена проверим, ничего ли не отвалилось.
12) Сооздам задачу ответственным для того что бы внесли необходимые НСИ, ну и естественно буду дергать ответственных за то что бы эти НСИ к нам попали сейчас это ведется как то и где то)
13) доработаю модуль расчета, если это необходимо (требования по нему еще не собраны, но предварительно при такой модели - они на данном этапе не понадобятся)
Это выбранная модель перехода, их было 3, самая геморройная, но гибкая, сегодня остановились на ней

(82) А как трансляция будет делаться "что бы они работали у нас, по нашему учету", если ты переносишь оттуда старые объекты МД, не "навешивая" ничего на них (или все-таки "навешивая")?

(83) Перенос идет не из 1с вообще, какая то система учета, доступ к которой имеется через веб, и они могут выгрузить файлик с данными. И они там всё ведут немножечко по другому.
Состав полей схожий.
То что у нас справочник - у них отдельная таблица, но данные, кроме последних не нужны.
И наоборот то что у них просто поле - у нас таблица.
Когда я сидел и по операционо смотрел как происходит работа и рассказал как она будет вестись, зная как у нас она сейчас ведется, их это устроило, они собственно похожие операции делали, только что то в екселе, что то в системе, дело ограничится обучением и небольшой косметикой в формах. В код постараемся по минимуму, времени не так много все таки.
Ну и все что в предыдущем посте написано тоже надо сделать.. Меня очень напрягает, что я завишу от файла с данными, запрос на который я сделал, а вот когда его получу, никто не может сказать, всё остальное за 10-15 часов делается в спокойном режиме...

(84) Это ты на фиксе так вкалываешь за оклад, что ли? )

(0)пункт 4 лишний.
пункт 1 спорный, так можно переругаться со всеми и тебя пошлют  первого.

(3) это пункт 0.

(86)Лучше переругаться, чем по 100500 раз выслушивать, что "Вы сделали какую-то фигню, мы все не так говорили". Хотя "говорили" именно "так".

(0)А вообще на это дело в нормальных организациях есть должностные инструкции.

(88) лучше "поговорить"  с человеком
,  а не требовать четко написанного тз в установленной форме.

(90) Ещё Джобс говорил, что пользователь не знает чего он хочет. Поговорить, конечно надо

(90)Лучше требовать четко написанного тз в установленной форме, а не "поговорить с человеком".

Но вопрос доверия.Если уверен, что человек потом не переобуется на лету, то можно и поговорить.

Но на все более-менее крупные доделки и доработки должна быть минимум служебная записка с описанием чего хотят с соответсвующими подписями.

1. Добиваться от пользователей четко сформулированные задачи к ИТ — отделу, с ТЗ

Ахаха, хочешь чтобы бухи и торгаши тебе указывали какие регистры и справочники создавать?

(92) ни разу не видел рядового пользователя способного написать внятное ТЗ

(94)Не поверишь какие навыки и способности открывает тот момент, что свою хотелку надо нести на подпись к Главному буху:-)  Половина хотелок умирает так и не родившись, а те которые доходят до подписи уже выглядят вполне вменяемо, потому что гбух тоже должна сначала понять что подписываает.

(91) я согласен. только еще добавлю : если бы он знал что хочет - все равно не смог бы это внятно выразить

(92) написать тз это работа. кто  будет делать эту работу, если есть своя ?

(88) я не общаюсь с "мы". все вопросы решаю с одним самым главным. как правило хватает просто разговора.

(97)>>кто  будет делать эту работу, если есть своя
Если ТЗ большое, то пишется совместно конечно. Но небольшие хотелки пользователь обязан сам зафиксировать. Хоте ели ты телепат, то можно и пропустить этот момент:-)
Выбор -дело личное. Если не боишься что потом будут проблемы и хватает простого разговора- то ради бога. Но я предпочитаю в этих делах хоть какой то порядок и чтобы я не был единственным ответсвенным.

(100) сто

+(99)Пототому что в случае если пожелания были ошибочны и, не дай бог,  их реализация привела к убыткам, то потом начинаются такие переводы стрелок и поиск виноватого - что мама не горюй!
Я предпочитаю не доводить до этого и подстраховаться.

(99) по моему опыту скажу так: требовать писать тз  - мне же во вред, задолбают мелочью и загадят всю почту этими хотелками.
и в конце концов кончится тем что напишут письмо в котором будет "нам надо встретиться и поговорить"

(101) ну верно.. пожелания фильтруешь, ошибочные удаляешь.. тз пишешь сам себе ))

(103)ТЗ пишется на бумаге, подписывается начальниками отделов - и в путь. Какие могут быть после подписания еще письма?

(103)Иногда да, пишу сам:-)  Для быстроты. Но обязательно подписываю у всех заинтересованных.

(95) Есть метод проще. Не общаться по пустякам с пользователями. Особенно по поводу доработок. Есть руковдятлы служб и самостоятельных подразделений. С ними можно что-то обсуждать и, по результатам обсуждения  включать в список задач на следующий период.

(106)Ну примерно так и есть. у нас запрещено начальком департамента что-то брать в работу от юзера в обход него. В идеале он сам стоит фильтром задач и решает что выполнять а что в корзину.

(104) два момента разных: 1 попросил написать тз юзера. и 2 написанное тз подкрепил подписью всех заинтересованных.

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

(92) Нужно просто спросить, чо он хочет и самому написать ТЗ, а потом попросить пользователя завизировать это ТЗ, чтоб на ходу не переобулся. Еще один немаловажный нюанс - ТЗ не должно допускать разночтений и содержать какие-то недомолвки.
Были прецеденты, когда пользователь отмазывался от своего же подписанного ТЗ, в том смысле, что имелось ввиду совсем другое, а не то что вы сделали или как вариант не доделали.

(109)Ну да.

(108)Принцип такой, то ТЗ должно быть. а кто его будет писать - это вопрос обсуждаемый.

(85) Да, но тут внезапно вплыло озарение, что часть работ можно сократить при помощи ФО, параметра ФО, и мктросокопической подписки, не придется перерисовывать часть интерфейсов, уж хорошо.
Но файл с данными подтвердил мои худшие опасения - это эксель с кучей просто всякого г-на, типо в разных колонках разный формат дат, разные разделители частей дат (но в пределах одной слава богу один и тот же), в ФИО фамилия имя отчество может разделятся произвольным количеством любых символов, фамилия от имени может разделятся 1, а может 2мя пробелами например,и куча подобных приятностей, завтра демо показ...

(99) "небольшие хотелки пользователь обязан сам зафиксировать. ... я предпочитаю в этих делах хоть какой то порядок и чтобы я не был единственным ответсвенным."

Есть такой вариант - выслушать, написать ТЗ, а потом показать пользователю. И спросить - все ли так? Если да, то можно делать. Просто, работа над ТЗ тоже должна быть оплачена в том или ином виде. Ты уже не кодер, ты специалист, работающий с заказчиком. Это бОльший уровень.

ПС: все настоящие специалисты так делают. Отделочники (хорошие) тоже не требуют, чтобы им четко расписали - "сюда слой шпатлевки, потом грунтовка (2 слоя), потом обои, на клей типа ХХ, углы так заделать, а лампочки и проводку делать таким-то способом".
Если это требовать, то заказчиков не будет.

(0) +10
Хорошо, что это написал. Полезно упорядочивать то, что знаешь. И мне было полезно прочесть.