Девелопмент роад-мап

Перед тем как вы преступите к захвату мирового господства, вершению великих дел, или к женитьбе —

Умные люди, не раз ходившие тропами разработки различных програмых продуктов, настоятельно рекомендуют составить план, и желательно раньше, чем вы приметесь к самой разработке. Я склонен верить умным людям. Вперед!

Взглянем поближе

Сперва-сначала, мы посмотрим на то что у нас есть. Разберемся с какими вещами ТэЗэшница справляется, а с какими нет. Пройдем по каждой кнопочке и окошку, пофантазируем, поразмышляем, и обрисуем задачи на карте разработки.

Взгляд на используемые технологии

Судя по дате самого первого ТэЗэ в БД (MySQL), а это январь 2014 года, при разработке ТэЗэшницы 1.0, использовались возможности php 5.4. На дворе сентябрь 2018 года, и мы будем использовать возможности php 7.0

Что же там в БД

Взглянем на то, что собственно система аккумулирует в базе, я приведу SQL запрос INSERT ко всем столбцам таблицы zakazi , чтоб вы воочию узрели весь лютый кошмар, там происходящий:

INSERT INTO `zakazi`(`nomer`, `ime`, `data_zakaza`, `firma`, `tel`, `email`, `web`, `ime_maketa`, `pechatni`, `material`, `material1`, `razreshenie`, `dlina`, `visota`, `kol`, `S`, `provarka`, `prokleyka`, `lyvers`, `karman`, `obrezka`, `laminaciy`, `vid`, `data_sdachi`, `data_dostavki`, `primechanie`, `edit`, `zametka`, `manager`, `otchet`, `Dir`, `Ruk`, `Pech`, `Ruk1`, `otcha1`, `otcha2`, `votch`, `vdir`, `vruk`, `vpech`, `vruk1`, `votch1`, `votch2`, `edit1`, `kosyk`, `brak`, `apolo`, `polka`) VALUES ([...])

Да, я тоже немножк опешил, когда первый раз увидел, в первую очередь, от подхода к неймингу, он противоречит всему что я изучал, в частности — правилам хорошего кода.

Что хранится в первых столбцах, я примерно понимаю, а вот в столбцах начиная с `otchet` — тут без поллитра не разберешься.

Стратегически-полезной информации сохраняется откровенно мало, и сохраняется немножко не так:

  1. Данные клиента — замешаны в одну кучу с мухами и котлетами, их необходимо вынести в отдельную таблицу.
  2. Используемый в заказе материал и его площадь — почти ок, можно даже кое-какую аналитику проводить.
  3. Менеджера, ведущего заказ — ок, но не запоминает исполнителей.
  4. Стадии прохождения заказа — информация хранится в Булевом виде, что не дает нам простора для аналитики, а менеджерам полной ясности картины. Мы будем записывать таймштамп и юзера, отметившего стадию пройденной. И стадий, кстати, гораздо больше.

Мне необходимо внедрить ТэЗэшницу 2.0, сохранив при этом возможность хоть как-то анализировать старые задачи.

Что будем делать с базой?

  1. Тотал ренейм! Чтоб глаз дергаться перестал.
  2. Создадим отдельную табличку для клиентов, не будем писать их в явном виде в задаче, будем подтягивать по айди.
  3. Тоже самое сделаем с материалами.
  4. Добавим стратегически-полезных полей.

Я, как печатник, хочу отмечать с какими профилями и настройками станка, будет печататься тот или иной заказ. Это даст прямое представление о скорости выполнения этого заказа. В разных режимах печати — разные скорости, и они известны, я хочу использовать эту информацию. Так-же это люто сэкономит мое время, когда придет чувак, печатавший у нас постер 3 года назад, и скажет: «- Вот новый макет, но сделайте плз чтоб вот тут зеленый был таким-же зеленым как и здесь».

Взглянем на форму составления ТэЗэ:

Мы имеем две формы. Когда-то была одна (на первом скрине). Вторая появилась 2 года назад, моими силами. Сейчас будет отступление к истории предприятия, его внутренней организации.

Когда-то, на производстве, было 2 печатных станка, и всё. С ТэЗэшками на печать эта форма худо-бедно справлялась. Но позже появился лазер и режущий плоттер. Потом еще пара печатных станков. Потом фреза.

С ТэЗэшками на фрезеровку и лазер она не справлялась, из-за организации БД. С задачами для макетчиков не справлялась по той же причине. ТэЗэшки макетчикам печатаются на бумаге, и передаются в руки. Для контроля исполнения задачи приходится ходить своим пешком в макетку.

Теперь оно кое-как контролируется. Всё так-же печатается на бумаге, но ходит и проверяет теперь только начальник производства, и ставит галочки во второй таблице.

Так сложилось исторически. Так сложилось от криворукости. От такого уклада у всех волосы дыбом. Я хочу объединить и формы, и таблицы в одну, хочу облагородить внешне, и принести дзен вовнутрь.

Хочу чтоб когда менеджер напечатал первые две буквы фамилии клиента, форма предложила варианты в автоподстановку, о которых уже знает.
Хочу, чтоб менеджер мог просто перетащить макет в форму, и она сама заполнила те поля, которые смогла прочитать.
Хочу чтоб форма подсказала менеджеру, что материала на производстве может не хватить на этот заказ, что нужно его докупить.
Хочу, чтоб она подсказала стоимость заказа.
Хочу чтоб менеджер мог иметь черновики. Чтоб мог пользоваться шаблонами для часто-одинаковых заказов. Хочу, чтоб менеджер не страдал, а работал быстро и эффективно.
Форма может помочь перестать делать двойную работу, и должна это делать.

Теперь к таблицам

Я их показывал прошлым постом, но взгляните, пожалуйста, на них еще раз:

Здесь нужно переделать абсолютно всё.
Я хочу иметь возможность сортировать задачи по материалам, по пособработке, по срокам сдачи, по клиентам, по менеджерам, скрывать отпечатанное, порезанное, заламинированное. Хочу отмечать профиля и настройки станка. Хочу отмечать на каком рулоне распакованного материала я напечатал это, а на каком вот это. Для чего? Чтоб понимать, сколько погонных метров в рулоне осталось.

Сейчас расскажу, как приблизительно прикинуть, сколько еще материала в рулоне:

Нужно посчитать «годовые кольца» и умножить на 30 сантиметров. Я устал так делать.

Хочу, чтоб менеджер мог развидеть поля, которые ему не хочется видеть, а в случае чего, увидеть снова. Чтоб перестал ломать глаза.
Для менеджмента, я намерен кардинально изменить представление задач. Я внесу, такую сущность, как кейсы.
Это будут такие папочки, внутри коротых будут лежать заказы от одного клиента, на настоящий момент времени.
Сейчас каждый макет — отдельное тз. В базе мы это так и оставим. Вот к примеру, у нас есть заказ от условного ООО «Рога и копыта», они хотят 3 баннера, и 5 постеров. Производству мы покажем их отдельными строками. Но менеджеру будем показывать кейс, внутри которого эти 8 строк будут сгруппированы, и опрятно отображены. Без вырвиглазности. Для глубоких раскопок внутри кейса — его можно будет развернуть, и посмотреть — скорректировать.

Чего еще нет, но хочется

Нет никакой системы управления юзерами, группами и тд. Вся админская работа ведется врукопашную, напрямую в бд и в коде.
Создадим эту самую одминку!

  • Чтоб старший менеджер мог зарегать нового менеджера, чтоб начальник печатки мог зарегать нового печатника, и тд.
  • Чтоб руководство могло работать с прайсом (от сюда, кстати, вырастет API)
  • Чтоб я мог добавлять новые материалы
  • Чтоб тот парень мог себе аватарку поменять, в конце то концов!

Хочется мобильную версию.

И так, теперь по пунктам

  1. Реорганизация БД.
    • Ренейм полей
    • Создание новых таблиц для клиентов и материалов
    • Добавление новых стратегически-важных полей
  2. Редизайн таблиц.
    • Изменение представлений
    • Добавление фильтров
    • Объединение двух таблиц в одну.
  3. Редизайн форм.
    • Объединение форм в одну
    • Добавление форме мозгов
  4. Одминка

Ну, вроде бы, общий план ясен.

Ой, совсем забыл о входе и регистрации. Там-ведь тоже конь не валялся

Начну я, пожалуй, с него. Об этом — следующий пост.

Поделиться
Отправить
Запинить
 16   2018