Дубликаты не найдены

+32

Скорее так

Иллюстрация к комментарию
раскрыть ветку 8
+10

Отдел маркетинга в избушке на курьих ножках шагает совсем в другую сторону.

+1

Обожемой. Что это за развалины башни справа? Что-то известное?

раскрыть ветку 5
+4

Я искал "дом из говна и палок" - вот оно и нашлось =)

раскрыть ветку 4
-1
Кто ж виноват,что отдел разработки не справился с задачей))
+15

Они же на пони едут.  Микрокавалерия

раскрыть ветку 1
+5
А срут как макси! 😊
+113

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

раскрыть ветку 29
+52
Жена подсказывает - с бухгалтерией такая же херня. Типа вы убытки, мы доход. Мы там чето где-то отгрузили хз кому, а вы разъебывайтесь. Наше дело продавать, а не с бумажками возиться. Хоть делом займётесь.
раскрыть ветку 9
+22

погоди они что едут на пони?

раскрыть ветку 2
+8

а хоть один не считает себя исключительным? Даже уборщица на предприятии королева.

раскрыть ветку 1
+4
Нам один раз экономист сказала, что они прибыль компании приносят, а не технологи разработчики. До сих пор пердак подгорает. Я значит рецептуры разрабатываю подешевле, эксклюзивные, а прибыль приносят экономисты...
+2

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

раскрыть ветку 2
+29

Ну нет продаж => нет денег => на хуй весь бэкофис нужен

Да все важны, чего уж там.

раскрыть ветку 9
+8
Ну так то да. Ещё в 91 году стало ясно, что нахер твои мощности не сдались, если сбыта нет, а все туда же)
раскрыть ветку 5
0

ну это уже проблема вождя а не индейцев - запускать бизнес который будет без продаж)

я так то внимательно курс Белфрода (волк с уол стрит) проходил и.. хороший продажник будет работать там где продукт конфетка. Нет такого продукта ни продажники не нужны ни бек ни @Kshishtov со своими доводами

раскрыть ветку 2
+7
Тут где-то был пост про казаков из Краснодара.
Срут и не убирают :)
раскрыть ветку 2
+22

А у них ещё и лошади срут кстати, заебали всех.

раскрыть ветку 1
+5
Собственно сам продажник и уверен что результат конечный это конечно деньги, которые добывают продажники, но без старания всех служб, обеспечивающих процесс, и без собственно самих специалистов разрабатывающих продукт - ничего бы не было.
Посему это командная история, где все важны и выполняют свою роль
+1

Айтишник как и электрик по дефолту нихера не делают, уже можно было бы и привыкнуть.

раскрыть ветку 3
+2
Это же сарказм?
раскрыть ветку 2
0
Зависит от продукта на самом деле. Если вы условный завод, который один в стране делает что-то уникальное, тогда да. Продажники тут на вторых ролях. Если конкурентный рынок, то тут как бы не хотелось побузить на "мальчиков и девочек", которые ничего не понимают в производстве без них никуда. Важны все, но в зависимости от ниши либо производство продукта будет флагманом, либо продажи, а производители должны будут подстроиться под требования. Альтернатива - вылет с рынка и очередная история на пикабу, как руководство не послушало простого мастера, который точно знал как лучше, и прогорело.
+5

А разве им не должны какие нибудь мешки или мотню под задние ноги подвязывать ? Не особо ведь торжественно, когда на параде, при камерах, кавалерия мимо трибуны идёт и непроизвольно серет.

раскрыть ветку 2
0

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

раскрыть ветку 1
+1

Ну видимо эти конюхи, легенд не слышали.

+3

Отдел ИТ

Иллюстрация к комментарию
+19

Подписи перепутаны, по моему.

Наразрабатывают, блин, продавай потом как хочешь!

раскрыть ветку 22
+2

С лопатой стоит сопровожденец, а разработчик уже в ужасе свалил в закат, зная, что будет дальше.

раскрыть ветку 2
0

Заставят рефракторить :)

раскрыть ветку 1
+3

продавец должен уметь продавать разве нет?

Иначе чего он тогда в профессиональном плане стоит?)

раскрыть ветку 14
+11

А разрабатывать уметь не нужно?

раскрыть ветку 13
-3

Тоже не врубился, сначала разработка же идёт, а потом продажи, а на картинке разработка убирает после продаж, хз

раскрыть ветку 3
+6
Потому что продажники могут напродавать доработок и напиздеть про нужные заказчику фичи, которых ещё нет. А потом разработка разъебывается пытаясь сделать все то, что обещали заказчику
раскрыть ветку 2
+3

Я как юрист вижу это так

Иллюстрация к комментарию
раскрыть ветку 2
0
Как же вы правы 😀
0
Люто плюсую, та же проблема с этими продаванами юридических услуг
+1
У всех своя работа). Если отдел продаж будет говорить правду, то скоро отделу разработки придется искать новую работу.
+1

У нас на работе наоборот. Косячат-косячат, а ты всё равно продавай и перед клиентами отчаянно отмазывайся, что всё будет красиво.

+1
Кони мелкие, а насрали по-крупному!
+1

Кто мешал отделу разработки коням под хвосты мешки повесить?

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

0
Понная полиция!
0
А где тэг "казаки"?
0
Орнул! Я так работал в одной фирме в отделе разработки как раз!
0

Ваш дизайн - гавно. Это дизайн говна. Тогда недурно.

0

на второй фотке отдел сопровождения

0

Фронтенд/бэккенд

0
Картинка без надписи есть?) Хочу свою сделать)
0
Отдел разработки и отдел сопровождения :/
0

Тогда лошади, это производство, на котором продажники выезжают

0
Иллюстрация к комментарию
0

А виновата столовка , шо гавном кормит :))

0

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

раскрыть ветку 2
-4

Попробуй не есть перед и во время рабочего днем. С голову не помрешь, и рабочее время не будет тратиться на акт дефекации.

раскрыть ветку 1
+1
Сообственно так и получается. И ничего- живой.
0

Так не только в IT. В машиностроении все тоже самое)

-1

Всё-таки, правда.

"Я продал вашего говна на 999999кккк мильёнов долларов за неделю! Да на мне компания держится! Если бы не наш отдел, ходили бы со своим говном никому не нужные! Мы деньги компании приносим, а вы просто за компами сидите!"

раскрыть ветку 14
+9
А это местами с молчаливой (а иногда и не молчаливой) поддержки руководства. Некоторые особо одарённые директора реально хуесосят отделы, которые не приносят прямого дохода. Тех же вон айтишников отчитывать за то что они денег вообще не приносят, а только просят на всякие железки, которые непонятно зачем нужны компании - за милую душу.
И рад бы я сказать что подобные шарашки долго не живут, но нет - отлично живут. Выходцы из 90х, когда у "фирм" был аж один отдел человек на пять, где каждый был продажником и всем прочим занимался в остальное время. Выжили, расширились, а отношение к сотрудникам осталось те же. Каждый, мол, должен приносить деньги.
раскрыть ветку 3
+2
Решается вопрос просто. Выносится отдел, не приносящий дохода, в отдельное юрлицо и заключает договор с основной фирмой за деньги. Пруфитом отчитываются перед хозяином. Все довольны. Не благодарите.
раскрыть ветку 1
-5

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

ещё комментарий
0
Ну, с другой стороны лошадей проектировал it-отдел. То что они срут сппоектировал itотдел. Убирать тоже должен it отдел.

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

Вот ттакая логика, малята))
раскрыть ветку 9
+1

А если реализация несрущей лошади невозможна? Ну вот просто технически программно невыполнима?

И предложение использовать костыль в виде мешка для сбора говна было отвергнуто, чтобы не отпугивать клиентов?

раскрыть ветку 2
0

Не правильная логика. По ней рано или поздно отдел ИТ будет заниматься уборкой за лошадьми, а не их разработкой.

раскрыть ветку 5
-1
Иллюстрация к комментарию
Иллюстрация к комментарию
раскрыть ветку 2
+1

Интересно, чем там история с бомжами кончилась...

раскрыть ветку 1
+1
Всегда ваш кэп.
Иллюстрация к комментарию
-1

Ну как работавший в продажах, а сейчас в разработке, то все наоборот.

Похожие посты
31

Что находится между идеей и кодом? Обзор 14 диаграмм UML

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Аве Кодер! Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?


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


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


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


Для тех, кому лень читать и кто предпочитает смотреть и слушать: https://youtu.be/0I9aIP5gKCg


Основные цели дизайна UML:

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

Обеспечить механизмы расширяемости и специализации для расширения основных понятий.

Быть независимым от конкретных языков программирования и процессов разработки.

Обеспечить формальную основу для понимания языка моделирования.

Поощрять рост рынка объектно-ориентированных инструментов.

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

Интегрировать лучшие практики.


Диаграммы UML подразделяют на два типа - это структурные диаграммы и диаграммы поведения.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

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


Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени.


Теперь пару слов о каждой из них


Диаграмма классов

https://youtu.be/sVVJp5a41o4


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


Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

-- Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.

-- Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.

-- Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма компонентов

https://youtu.be/OiVyha3sf_I


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


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

Эти программные компоненты включают в себя компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма развертывания

https://youtu.be/Yz8phtJoP7I


Диаграмма развертывания помогает моделировать физический аспект объектно-ориентированной программной системы. Это структурная схема, которая показывает архитектуру системы, как развертывание (дистрибуции) программных артефактов.

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


Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма объектов

https://youtu.be/tVW5oHNfAvc


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

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма пакетов

https://youtu.be/237BWanM4Ak


Диаграмма пакетов - это структурная схема UML, которая показывает пакеты и зависимости между ними.

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма составной структуры

https://youtu.be/nsuJcMNaKeE


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


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма профилей

https://youtu.be/qBws7AfvDL8


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма прецедентов

https://youtu.be/BdAcxboG5No


Диаграмма прецедентов описывает функциональные требования системы с точки зрения прецедентов. По сути дела, это модель предполагаемой функциональности системы (прецедентов) и ее среды (актеров).

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма деятельности

https://youtu.be/Z8PHBsNXAgc


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

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

В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма состояний

https://youtu.be/ojCcUvGfpi8


Диаграмма состояний - это тип диаграммы, используемый в UML для описания поведения систем, который основан на концепции диаграмм состояний Дэвида Харела. Диаграммы состояний отображают разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Она помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма последовательности

https://youtu.be/ycg3njrkk1c


Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма Коммуникации

https://youtu.be/KVLJj9xOq0E


Как и диаграмма последовательности, диаграмма коммуникации также используется для моделирования динамического поведения прецедента. Если сравнивать с Диаграммой последовательности, Диаграмма коммуникации больше сфокусирована на показе взаимодействия объектов, а не временной последовательности. На самом деле, диаграмма коммуникации и диаграмма последовательности семантически эквивалентны и могут перетекать одна в другую.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма обзора взаимодействия

https://youtu.be/E0OJG8ojEAg


Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Временная диаграмма

https://youtu.be/NKTyDQUkLoM


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма
Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Зачем в UML столько диаграмм?


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

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

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

Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.

UML пытается предоставить язык настолько выразительным образом, что все заинтересованные стороны могут извлечь выгоду, как минимум из одной диаграммы UML.



Аве!

Показать полностью 17
104

Про собственную глупость или как не нужно фрилансить

Расскажу историю, в которой я, по доброте душевной, вляпался во все то, от чего нужно сразу бежать любому фрилансеру.


Да, сам я уже 10 лет занимаюсь разработкой ПО, фрилансом в чистом виде никогда не занимался и на грабли за эти 10 лет не наступил ни разу. Ну хотя бы потому что до того 15 лет админил и фрилансил, хотя тогда это еще называлось не так:) Да и большую часть халтуры с коллегами проводим через ООО или по договорам с заказчиками. Но, как говорится и на старуху бывает проруха.


Ладно, это все лирика, теперь сама история. Дальше много букв.


Еще во времена админства, познакомился я с одной конторой, которая занималась написанием узкоспециализированного софта. Наша компания этот софт использовала, соответственно общались плотно. Даже после того, как я уволился. Раз в год приходили товарищи с вопросами как дела, иногда предлагали что-то написать для них. Но я стойко отбрехивался, так как профиль ну совсем чуточку не мой :) Либо ковырялся с их вопросами в режиме "самому интересно", без оплаты. Кстати, именно по их задаче разобрался в свое время во многих вопросах работы модулей ядра линуха.


И тут пришли они в очередной раз, с просьбой немножко перепилить скрипты для luci - это такая web-based система управления роутерами на OpenWRT. И попали они в тему. Еще один намечавшийся проект планировался как раз на ВРТ и тоже с возможной допиской люси. Жадность до знаний и денег задушила сомнения и я согласился. Причем согласился, идиот, по ТЗ в виде комментариев через скайп и без договора. Ну а чего? Мы же знаем друг-дружку много лет!


Изначально задача звучала так - нужно немножко поправить скрипты люси, так, что бы можно было из вебморды управлять их проприетарным софтом. Ну кое-как оговорены сроки (в 1 месяц) и объем. Это, кстати, был июль месяц прошлого года.


Ок. Пилю скрипты попутно разбираясь с люсей. Знакомлюсь с их главой разработки, сурьезный чувак, руководил разработкой в очень большой и всем известной компании. Попутно выясняется, что помимо скриптов, надо еще и дизайн поменять. Ну думаю ок, хрен с вами. Говорю что верстку делать не буду, не умею правильно, могу только рассказать как это нужно сделать, что бы все натянулось на люсю. Да-да, отвечают мне. И рождается, т.н. ТЗ, которое суть есть описание страничек и пошаговое описание чего где происходит. Оно кстати исключительно по моей инициативе родилось, и впоследствии со скрипом изменялось раз наверное 15. Причем то и дело новые пункты отменяли предыдущие с соответствующими переделками.


Уезжаю в отпуск и пилю все это там, жду готовый дизайн. Причем дизайнеру детально рассказываю про все особенности люси(там верстка частично интегрирована в шаблоны, частично снаружи и вся сделана определенным образом), рассказываю как нужно все это сверстать, что бы мне пришлось минимально переделывать. Естественно все это вместо разглядывания бесконечных и так мною любимых рапанов и крабов на дне Черного моря. Ну хоть на пляжу посидел.


Приходит дизайн. Пля. Ни одного совета и рекомендации не выполнено. Вместо div все таблички table. Классы css не то что не похожи на то что нужно, они вообще не имею ничего общего с люсей. И т.п. В общем нужно все взять и переделать. Обсуждаем, принимается решение натянуть "как сможешь". В общем я еще пару недель трачу на выпиливание из кривого дизайна нечто похожее на люсю. Попутно ругаюсь с главой разработки, во-первых из-за постоянных багов их ПО то и дело всплывающих, во-вторых из-за попыток загнать меня в их git. Прямо сказал товарищу, что договора у меня с ними нет, так что никакого их git, только мой. В их после 100% оплаты :) Он там, говорят, так возмущался! Так возмущался, что перестал со мной общаться.


Ок, после всего этого, натянул дизайн, допилил скрипты, отослал. И тут, как в старом анекдоте, блин, концепция изменилась. Оказывается первый дизайн - унылое говно и такое инвесторам показывать нельзя! То есть вы представляете себе уровень коммуникаций у них там, внутри конторы? Когда руководитель разработки вообще не знает, что делает руководитель проекта и разработчик, потому что с последним он поругался :) Соответственно нужно дизайн переделать. Для чего через пару месяцев находится какая-то студентка "умеющая" верстку. Мне поручается студентке все рассказать, и проконтролировать. Ок, рассказываю 4 раза студентке, как нужно сверстать странички, девочка говорит "ага, я все поняла" и уходит ваять на пару с дизайнером. Еще месяца полтора или два они там на пару рожают дизайн. После многочисленных пинков дизайн присылается мне. Пля-пля. Опять тоже самое, что и в первый раз. Ни одна рекомендация не выполнена :) То есть нужно взять, разодрать весь дизайн на кусочки и опять адаптировать под то что нужно, ну то есть переделать всю работу верстальщицы. Далее следует уже ругань с руководителем прожекта, очередное объяснение верстальщице и дизайнеру как нужно сделать и пауза в полтора месяца. После которой мне присылают "исправленный" дизайн. В котором, вы удивитесь, все тоже самое что было раньше. В том же виде :)


В общем, пришлось отказаться от дальнейшего сотрудничества.


По факту имеем, вместо примерно месяца неторопливой работы почти по профилю и 60 тыщ рублей легких денег, 7 месяцев мозгоклюйства с версткой, обучением верстальщицы и дизайнера, и 20 тыр, очень удачно выцыганенных где-то между предпоследним и последним дизайном (это после 6 месяцев, да) + стойкая ненависть к люсе, верстке и lua :)


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


Резюме, чисто риторически, так как тут все кристально ясно:


1. Обязательное согласованное ТЗ, неважно кто его пишет, сам заказчик или вы для него. Причем ТЗ оплачивается отдельно.


2. Договор, в котором описаны сроки и к которому, впоследствии, привязано согласованное ТЗ


3. Все доптребования, коррективы и т.п. только по согласованию и только за дополнительную плату


4. Ну и по возможности не делитесь с заказчиком своей работой, пока она не оплачена.

Показать полностью
764

Любые совпадения с жизнями всех айтишников мира – всего лишь совпадения

Любые совпадения с жизнями всех айтишников мира – всего лишь совпадения Комиксы, IT, Служба поддержки, Жизнь, Юмор, Разработка, Длиннопост
Любые совпадения с жизнями всех айтишников мира – всего лишь совпадения Комиксы, IT, Служба поддержки, Жизнь, Юмор, Разработка, Длиннопост
Любые совпадения с жизнями всех айтишников мира – всего лишь совпадения Комиксы, IT, Служба поддержки, Жизнь, Юмор, Разработка, Длиннопост

На всякий, как найти нас в соцсетках:


Мы в ВК https://vk.com/dodopizzaio?z=photo-159959555_457239396%2Fwal...

Мы в FB https://www.facebook.com/dodopizzaio/posts/1632627370206946?...

Показать полностью 2
Похожие посты закончились. Возможно, вас заинтересуют другие посты по тегам: