Андрей Титов

Внезапно стало неудобно и непродуктивно общаться с заказчиками, которых набралось под 50 и с ними нужно взаимодействовать и отслеживать состояние процесса разработки в актуальном состоянии одновременно.

Способы коммуникации по степени убывания эффективности:

• личное общение
  
• видеосвязь (скайп и пр.)
  
• телефон
  
• переписка
  

В вашем случае, в тикетах рекомендую фиксировать только итоги устных договоренностей.

Как унифицировать отдельное хранение файлов и документов - кто то одним файлом ТЗ шлёт, кто то порознь и в разных форматах?

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

Как организовать демонстрацию результатов и сбор фидбэков по ним?

Предварительные демо поднимаете на своем сервере. Показываете сами или даете доступ. Фидбэк устный получаете в ходе показа (фиксируете письменно), фидбэк письменный от самостоятельного ознакомления просите прислать сразу в тикеты или почтой. Приемку проводите по плану приемки, который должен быть частью ТЗ. Финальный фидбэк - подписание актов.

Как организовать совместное с заказчиком участие в процессе тестирования?

Обычно заказчик соглашается на участие в тестировании в следующих случаях:
a) заказчик внутренний, b) низкое доверие к вашему тестированию или c) заказчик хочет съэкономить и согласился тестирование взять на себя. В остальных случаях - тестирование - это ваша задача. Заказчик хочет получить демонстрацию и увидеть, что все прекрасно, а не ваши баги. Ну а если смотреть шире, то любое обнаружение бага в ходе эксплуатации, является тестированием силами заказчика. :)

Андрей, у вас получается пул разных задач и под них целесообразно использовать разные системы:

Внезапно стало неудобно и непродуктивно общаться с заказчиками, которых набралось под 50 и с ними нужно взаимодействовать и отслеживать состояние процесса разработки в актуальном состоянии одновременно.

Для управления коммуникациями с заказчиком - CRM-система (их множество, я работаю в bpm'online), в ней фиксировать все контактные данные, связи между клиентами и контактами, планировать встречи и звонки, желательно туда же завернуть электронную почту.

Процесс разработки - система управления проектами, можно в самой CRM-системе вести список объектов их статус, сроки и % выполнения.

Почта перестаёт работать, как инструмент коммуникации, после вложенных друг в друга 15 сообщений. Разбивка сообщений по темам и сообщениям объём переписки только увеличивает и запутывает.

Обсуждение отдельных организационных тем всё равно придётся вести в почте - это самый эффективный на данный момент инструмент, позволяющий фиксировать историю и договорённости. Разбивать переписку по темам - хороший вариант, в конце договорённостей - резюме.
Обсуждение проектных задач вынести в систему описания задач (можно пользоваться любой wiki-системой, начиная от платной Confluence, до MediaWiki и т.п. или использоваться связку NextCloud+LibreOffice Collaborate для командного онлайн-редактирования документов - я пользуюсь вторым набором).

Как унифицировать отдельное хранение файлов и документов - кто то одним файлом ТЗ шлёт, кто то порознь и в разных форматах?

Определить свой формат ТЗ и приводить все документы к единому виду и единой структуре. И своё хранилище с разграничением доступа (я, опять же, пользуюсь NextCloud)

Как организовать демонстрацию результатов и сбор фидбэков по ним?

Перед передачей результата работ в тестирование составить тест-кейсы, в которых с одной стороны должно быть описаны действия пользователя и плановый результат, а с другой стороны пользователь укажет что у него реально получилось и какие замечания. Для этого тоже есть свои системы, мне пока обычных текстово-табличных документов хватает - если делать ТЗ в виде пользовательских историй, то их же потом можно в качестве тест-кейсов использовать.

Как организовать совместное с заказчиком участие в процессе тестирования?

Этот процесс лучше разделять на три: внутреннее тестирование + обучение + тестирование заказчиком с заполнением тест-кейсов.

Можно ещё почитать книгу М.Кон Пользовательские истории - неплохо описан процесс и порядок организации Agile-разработки.

Никак, скайп для линукс это веб-версия в обертке, в веб версии нет демонстрации экрана.

В первом случае ты передаешь в newArr указатель на массив, потом изменяешь этот же массив через указатель arr.
Во втором случае ты снова передаешь указатель в переменную newArr, а потом просто присваиваешь переменной arr другое значение, то есть убираешь из нее указатель, но не затираешь само значение. Мало того - ты вручную вообще никак не затрешь значение любого объекта, ты можешь только "забыть" о нем, а уберет его за тебя уже либо сборщик мусора, либо просто вся выделенная память затрется при перезагрузке страницы.

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

Vanilla.js - это шутка. Подразумевается Ecmascript.
Работодатели намекают, что Вы должны владеть всеми основными возможностями, которые предоставляет язык.

Это значит что html-разметка в полном объеме формируется на веб-сервере. Значит не используются javascript-фреймворки для отрисовки страницы на стороне клиента. Да, и успокойте меня, скажите что знаете перевод глагола render в контексте программирования?

1. In apps.py:

from django.apps import AppConfig

class FacesetConfig(AppConfig):
    name = 'faceset'
    verbose_name = "Что-то твое на русском на родном"

2. models.py

class Timetables(models.Model):
    name = models.CharField(u'time', max_length=30)

    class Meta:
        verbose_name = 'Что-то твое на русском на родном'
        verbose_name_plural = 'Что-то твое на русском на родном'

    def __str__(self):
        return self.name

Пробовал два сервиса:

1. Onpay.ru - не очень качественная документация, периодические проблемы с оплатой у клиентов.
   Запутанная система с выводом средств. Впечатление осталось не очень от сервиса. Средненькие цены.
   
2. Яндекс.Касса - хорошая документация, "долгая" техподдержка, по самим платежам от клиентов претензий практически не было. Личный кабинет активно развивают, добавляют новые функции. Средства выводятся на Р/С на следующий день после совершения платежа. Высокие цены, но удобство пользования пока окупает все недостатки.
   

Вообще советую вам для начала почитать про 54-ФЗ, т.к. с пробитием чеков сейчас тухляк. У той же Я.К. есть 2 решения - 3к в месяц или 28к касса и 1к в месяц (без учета % за транзакции) - как то дорого для магазинчика с небольшим оборотом.

https://github.com/Automattic/mongoose/issues/4291

Добавьте mongoose.Promise = global.Promise; перед mongoose.connect(...)

1. Удалите папку из git: git rm -r --cached node_modules
2. В .gitignore должно быть прописано node_modules/.
3. Ну и закоммитить изменения, само собой.

Андрей, вы не представляете какая это огромная проблема. Я занимаюсь сопровождением проектов и на каждом одно и то же...

Если порог входа в область высокий - заказчик советами не лезет. Если порог входа низкий - контролировать будут каждый шаг. Не дай бог заикнуться про UX, заказчик вам нарисует все как положено.

По факту, таких областей немного: дизайн, анимации, звуки и СЕО. Во всех трех заказчики проявляют недюжую активность, несмотря на полное отсутствие знаний, или даже вкуса. Спорить бессмысленно. В редких случаях можно аргументированно объяснить почему, к примеру, цветовая палитра имеет два ярких цвета (а не один, или 10). Бывают что понимают и тогда... появляются вопросы к другим элементам.

Для этого я всегда опрашиваю заказчика, делаю картину референса. Обычно это 10-100 работ, которые нравятся. В таком объеме сразу видны предпочтения (в цвете, тенях, размерах и пр.) и дизайнеру выставляется т3 с ограничениями. Это конечно не хорошо, но в большинстве случаем работает. Важно правильно сделать выборку того, что нравится заказчику.

В СЕО я много говорю о планах проекта, о том, как видят заказчики развитие. В этой сфере аргументировать проще, хотя и порог входа все равно невысокий (заказчик с радостью даст совет)

Ранее я был полон энтузиазма и старался делать как лучше проекту. Но эти споры... позиции пришлось сдать и подстроится.

В других сферах, более сложных (API / архитектура / протоколы и выбор алгоритма шифрования...) заказчик не появляется, слишком сложные чтобы давать советы.