Çalışma bölümündeki kurallar - sayfa 5

 
Yedelkin :
Ve işte sorunu çözmek için kavramsal olarak farklı bir yaklaşım :)
Soru yok. )))
 
pronych :

Kaynak kodu, bir dizi ek özellik, sınıf vb. ile iyi tasarlanmış bir şablon olabilir. Bir grup bloktan oluşabilir (örneğin içerir) ve yalnızca içindeki bazı koşullar farklılık gösterebilir. Sadece sinyal modülünün farklı olduğu bir sistemin (birbirleriyle etkileşim anlamında sistemler) bir düzine farklı dosyadan kaynak kodlarında yarım yıllık (basit bir durumda) çalışma süresi vermeye hazır mısınız ( bir sınıf (dosya))?

Damaların kesişimini kesmek için standart yöntemler kullanabileceğinizi anlıyorum ve bu üzücü değil. Ve eğer şablona muazzam bir iş yatırılırsa, o zaman nasıl? Hayır, hazır mısın?

Bu gibi durumlarda, şablonu derlenmiş bir dosya ve sinyal modülü olarak - Müşterinin takdirine bağlı olarak vermenin daha iyi olduğu ortaya çıktı. Bu seçenek (daha önce bahsedilen) herkes için uygun mu?

... Ancak bu durumda "yeni yapı" riski Müşteri'ye geçer ve böyle bir riskin ortadan kaldırılmasının garantisi sadece Yüklenicinin vicdanına kalır.

 
Yedelkin :

Burada temel bir hata var. Sözleşme, iki veya daha fazla kişi arasında yapılan bir anlaşmadır. Bir başvuru, tek başına bir sözleşme olarak kabul edilemeyen, yalnızca bir tarafın teklifidir. Tartışılan Kuralların özüne dayanarak, sözleşmeye dayalı ilişkilerin ortaya çıkması (bir sözleşmenin imzalanması) ancak İş Tanımı'nın uygulanmasından sonra değerlendirilebilir. Her iki tarafça mutabık kalınan işin tüm detaylarını yansıtması amaçlanan İş Tanımı'dır.


Bizim durumumuzda uygulamanın bir sözleşme olduğunu iddia etmedim, sadece ona yakın olmasını diledim (yani, uygulama bence bazı zorunlu alanlar / onay işaretleri içermelidir) ve TOR'un açıklama yapması gerekir. daha ayrıntılı olarak yapılan işin özelliklerini ve icracının uyması gereken belirli noktaları belirleyin.

Aynı zamanda, programcı olmayan tüccarların en az %60'ının TOR'un yarısını görmezden geleceğinden eminim.

 
Interesting :

Bizim durumumuzda uygulamanın bir sözleşme olduğunu belirtmedim...

ilginç :

...Sanırım normal şartlar altında sözleşme (uygulamayı okuyun) ...

Her zamanki gibi, vurgulananları yorumladım :)
 
Interesting :

Aynı zamanda, programcı olmayan tüccarların en az %60'ının TOR'un yarısını görmezden geleceğinden eminim.

Bu nedenle, İş Tanımlarını (belirli Kurallar ışığında) derlerken, Yüklenicinin işin detayları üzerinde anlaşmaya varmak ve bunları belgeye yansıtmak için cesurca inisiyatif alması gerektiğini savundum ve savunmaya devam ediyorum. Çünkü, bu durumda Müşteri'nin iddialarını tazmin etmek zorunda kalacak olan Yüklenicidir. Ve Yüklenicinin kusuru ile beceriksizce hazırlanan İş Tanımı, sadece gereksiz anlaşmazlıkların ortaya çıkmasına katkıda bulunacaktır.
 
Yedelkin :
Bu gibi durumlarda, şablonu derlenmiş bir dosya ve sinyal modülü olarak - Müşterinin takdirine bağlı olarak vermenin daha iyi olduğu ortaya çıktı. Bu seçenek (daha önce bahsedilen) herkes için uygun mu?
Pek değil, herkes için.)) Ancak, aynı zamanda, elbette, bir seçenek ... Benim için hazır bir dosyanın olması daha uygun. Bu, görevi karmaşıklaştırır ('maliyet'i okuyun) Ancak konuşma bununla ilgili bile değil. böyle bir yaklaşım fikri dallandırır ve müşteri aptal olmasa da bu tür şeylerde bocalamaz (ya da karıştırmaz! farklı olabilirler))) “Kaynak kodu istiyorum” onay kutusunun yeterli olduğunu düşünüyorum ve bu tz anlaşmasından önce sorunların çoğunu çözecektir. Bu soru açıksa, görevi daha fazla tartışabiliriz. ve orada, çim büyümese de, tamamen farklı bir aşama.
 
pronych :
Pek değil, herkes için.)) Ancak, aynı zamanda, elbette, bir seçenek ... Benim için hazır bir dosyanın olması daha uygun. Bu, görevi karmaşıklaştırır ('maliyet'i okuyun) Ancak konuşma bununla ilgili bile değil. böyle bir yaklaşım fikri dallandırır ve müşteri aptal olmasa da bu tür şeylerde bocalamaz (ya da karıştırmaz! farklı olabilirler))) “Kaynak kodu istiyorum” onay kutusunun yeterli olduğunu düşünüyorum ve bu tz anlaşmasından önce sorunların çoğunu çözecektir. Bu soru açıksa, görevi daha fazla tartışabiliriz. ve orada, çim büyümese de, tamamen farklı bir aşama.

Sonra ne olur? Sorununuz için çalışan bir çözüm şöyle görünür:

1. Resmi tarafta - Kurallarda yeni bir paragraf ;

2. Teknik tarafta - Başvuru formunda, varsayılan "Gerekli değil" ile "Kaynak kodu gerekli" seçeneğini girin?

 
Yedelkin :
Bu nedenle, İş Tanımlarını (belirli Kurallar ışığında) derlerken, Yüklenicinin işin detayları üzerinde anlaşmaya varmak ve bunları belgeye yansıtmak için cesurca inisiyatif alması gerektiğini savundum ve savunmaya devam ediyorum. Çünkü, bu durumda Müşteri'nin iddialarını tazmin etmek zorunda kalacak olan Yüklenicidir. Ve Yüklenicinin kusuru ile beceriksizce hazırlanan İş Tanımı, sadece gereksiz anlaşmazlıkların ortaya çıkmasına katkıda bulunacaktır.

Evet. Bu muhtemeldir. O halde hemen tekrar düşünelim (geliştiriciler uyurken sessizce)), 'İş' bölümünde ne gibi eklemeler yapmak istiyoruz? Ama ben ilkim!

Ben bir dava istiyorum! 'kaynaklar'

:))

 
Yedelkin :

Sonra ne olur? Sorununuz için çalışan bir çözüm şöyle görünür:

1. Resmi tarafta - Kurallarda yeni bir paragraf ;

2. Teknik tarafta - Başvuru formunda, varsayılan "Gerekli değil" ile "Kaynak kodu gerekli" seçeneğini girin?

Doğru
 

Bence, başka bir alternatif yol var - yüklenici ile müşteri arasında belirli bir aracı-hakem (bizim durumumuzda, MQ) dururken, yüklenici tüm malzeme paketini + kaynak kodlarını aracıya (kim kontrol eder) aktarır. TOR'a uygunluk için), daha sonra müşteriye aracıdan aldığı işin tamamlandığı bildirilir ve bunun bedelini ödemekle yükümlüdür.

İşin münhasırlığına ve ilk sözleşmelere bağlı olarak, ödeme yapıldıktan sonra müşteri en açık kaynak kodunu veya sadece derlenmiş dosyaları alır.

Aynı zamanda, anladığınız gibi, aracı belirli bir ücret alır.

not

Bana öyle gelse de MQ pek hoşuma gitmiyor...

Neden: